Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Escape Analysis?  (Read 13228 times)
0 Members and 1 Guest are viewing this topic.
Offline ewjordan

Junior Member





« Posted 2008-03-04 02:22:43 »

I'm a bit confused.  From what I remember, escape analysis was supposed to automagically solve many of our temporary small object woes (as per http://www.ibm.com/developerworks/java/library/j-jtp09275.html) in the Java 6 release.  But I'm not seeing the improvements.  I'm working on JBox2d (a physics engine: http://www.jbox2d.org), and we are overwhelmingly bottlenecked by Vec2 creation costs, which was one of the things I was under the impression escape analysis would fix, as these objects are extremely short lived, mainly just used for shuffling pairs of numbers from place to place.  Frankly, things seem to be performing just about the same as in 1.5.  There still seems to be almost a 2:1 performance difference when I fully inline temp vector creations in realistic benchmarks.

What's going on here?  Was escape analysis cut from the JVM, or am I misinterpreting what it should be doing for me?  I'm quite happy to inline all that stuff by hand if need be, or reuse a few static vectors, but that IBM article seemed to strongly advise against that type of stuff (the author all but implied that anyone that would consider it is a freaking idiot).
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2008-03-04 06:37:53 »

afaik, its not been default activated yet

Offline CommanderKeith
« Reply #2 - Posted 2008-03-04 07:18:19 »

Apparently it's in, but it looks like you need to add some VM arguments (and maybe it's only for the server VM?):
http://blog.nirav.name/2007/02/escape-analysis-in-mustang-ii.html

Riven did some good benchmarks showing the problems:
http://www.java-gaming.org/forums/index.php?topic=14940.0
He tested on java 6 (Mustang), but didn't use the VM args given in the above link (I think...)

By the way, it's great that you're working on optimisations to JBox2D

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2008-03-04 13:17:57 »

That guy should be really more careful about using silly abbreviated variable names...

Cas Smiley

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #4 - Posted 2008-03-04 17:31:46 »

Apparently it's in, but it looks like you need to add some VM arguments (and maybe it's only for the server VM?):
http://blog.nirav.name/2007/02/escape-analysis-in-mustang-ii.html
interesting. (even if its not used to speed up object deallocation)
I recently asked in the comments of this blog enty if the server compiler would provide enough information to recognise "cheap garbage" and got as answer that this technique [escape analysis] won't have any performance gain with the current memory model (read the comments).

It seems even sun VM devs are not up to date with the -XX: flags  Undecided

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2008-03-04 19:14:39 »

That guy should be really more careful about using silly abbreviated variable names...

Cas Smiley

It was mostly autogenerated code. Tongue

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ewjordan

Junior Member





« Reply #6 - Posted 2008-03-05 01:14:58 »

Thanks, guys - going through some of those links, I came across http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-3412.pdf, where I found the following quick summary:

Quote
Implementation Status
- Java SE 6 has escape analysis and lock elision in the server compiler.
- It is off by default, it can be enabled with the  -XX:+UseEscapeAnalysis flag.
- Java SE 7 will have further optimizations.
- There are currently no plans to release a client compiler with escape analysis.

That last one is a shame - that means that as advanced and helpful as these optimizations are, they will be absolutely useless as far as game programming goes, right?
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2008-03-05 11:51:03 »

Well, unless you ship with the server VM, and then suffer horrible startup.

But... where does the tiered compiler fit in?

Cas Smiley

Offline CommanderKeith
« Reply #8 - Posted 2008-03-05 12:38:54 »

That was a great set of slides, thanks ewjordan.

Cas: the slides have info about escape analysis. Also Clemens (LinuxHippy) posted this, apparently it's in java 7:  http://www.java-gaming.org/forums/index.php?topic=16653.0

Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2008-03-05 15:12:45 »

Yeah I know - but, if they are not adding EA to the client VM... but they're axing the separate client and server VMs... what's actually going on here in the roadmap? I mean, we all know the ideal situation would be one single VM with EA, but it's not really clear if or when that's going to happen.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ewjordan

Junior Member





« Reply #10 - Posted 2008-03-05 18:01:45 »

I'm starting to feel like a standard refrain is emerging when it comes to problems of any sort in Java, especially the ones that tend to plague game development:

1) "There is no problem.  Your microbenchmarks are just wrong"
2) "Okay, there was a problem, but it's already fixed."
3) "No, really, it's fixed - and your new microbenchmarks suck, too."
4) "Alright, it's not quite fixed, but it's in the next JVM."
5) "On second thought, never mind.  It's not a problem again.  Look, we've got a great new feature for processors with 64 cores, isn't that better?"
6) "Screw you guys, real Java programmers don't care about this.  Go use C# if you want to make games."

Maybe I'm being a bit cynical and overly harsh (definitely am, sorry!), but looking at the relative performance increases between the Flash player and the JVM over the past few years, I'm starting to cross my fingers and hope that the Flash VM does in fact start supporting Java code as was rumored on another thread, if only because it's a platform where the desktop consumer is considered worthy of optimizing the VM for.  I'm getting ahead of myself, for sure, because the Flash VM is still quite a bit slower than the Java one (and it definitely doesn't have escape analysis), though the gap is closing (when I get around to running them I'll post some current test results in another thread).

Sorry to vent, I'm just getting frustrated from the constant choosing between maintainable and fast code, especially when this particular problem (small object overhead) has several different solutions and Sun seems reluctant to implement any of them.  Maybe what they say is true, and I keep trying to write Java code to do things that are better done in C++ (math, physics, and finance), but I'm really hoping that's not the case, because Java is a lot more fun to code and a lot easier to deploy!

Does anyone know much about the internals of EA and why it might be more difficult or expensive to implement on the client VM?
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #11 - Posted 2008-03-05 21:14:47 »

judging from bugparade your not too far of the mark, then again james gosling said

http://www.parleys.com/display/PARLEYS/The+Closures+Controversy
10.       Don't fix it until it chafes
"Just say no until threaten with bodily harm" 

Ok he said later this:
http://blogs.sun.com/jag/entry/closures  Wink


It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline CommanderKeith
« Reply #12 - Posted 2008-03-06 01:32:12 »


Does anyone know much about the internals of EA and why it might be more difficult or expensive to implement on the client VM?

Ken Russel might be able to give us some pointers.  By the looks of the slides you posted though, it seems like the problem is with mixing VM enhancements.  With method inlining, it's harder to figure out if a variable escapes or not. At least that's what I thought the slides said...

Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2008-03-06 12:32:03 »

I thought it'd be easier... after you've performed all your inlining to whatever depth, you'd then perform escape analysis on the resulting code. If any methods have already had EA performed on them before inlining, so much the better because then that code doesn't need analysing.

Cas Smiley

Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #14 - Posted 2008-03-06 19:34:54 »

Hi again,

I'll try to answer some questions to my best knowledge ... but if I am wrong, I am wrong Wink

Quote
Does anyone know much about the internals of EA and why it might be more difficult or expensive to implement on the client VM?
The idea of the client-compiler is to do cheap optimizations so that code can be compiled fast - it wouldn't make much sence to add an expensive (and optimistic) optimization like EA. The server-compiler is the place where it belongs to and with the tired compilers you should be already be able to benefit from it with the JDK7-ea builds.


Quote
'm a bit confused.  From what I remember, escape analysis was supposed to automagically solve many of our temporary small object woes
.............
It seems even sun VM devs are not up to date with the -XX: flags
EA != Stack allocation. EA is a step to gather information which can be used to du stack allocation and several other optimizations.
So EA is implemented and already some simpler optimizations which use the information gathered by EA, but stack allocation is not done till now.

Currently there seems to be some work on using EA for doing scalar replacement, something which should help to remove some of the memory preasure 64-bit systems suffer from (also a win for 32-bit systems) Smiley

lg Clemens
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2008-03-06 22:30:38 »

They can be sceptical all they like - it's already implemented in Excelsior JET and it works.

Cas Smiley

Offline bienator

Senior Member




OutOfCoffeeException


« Reply #16 - Posted 2008-03-07 17:02:01 »

They can be sceptical all they like - it's already implemented in Excelsior JET and it works.
They didn't say it wouldn't work. But they are sceptical if the "cheap to collect object detection" would provide any gain in overall throughput compared to the compacting technique.

The only advantage I see is the decreased pause time (even if it may run slower or with equal speed) but It may result in longer compile times too (->pauses).

IMO the main reason why there is a attempt to implement EA in the server compiler is concurrency. A lot of tricks are possible if you are able to detect thread private resources (eg allocation directly into registers, removal of locks...).

But don't get me wrong I am also very curious how it would perform.

Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2008-03-07 17:54:30 »

Well - I seem to recall the JET guys got EA working and stack allocation in linear time, meaning its impact on actual compilation performance should be minimal. I'm rather hoping that EA and stack allocation make it possible to start using the enhanced for loop and so on without creating tons of unnecessary garbage.

Cas Smiley

Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #18 - Posted 2008-03-08 14:55:02 »

Quote
Maybe I'm being a bit cynical and overly harsh (definitely am, sorry!), but looking at the relative performance increases between the Flash player and the JVM over the past few years, I'm starting to cross my fingers and hope that the Flash VM does in fact start supporting Java code as was rumored on another thread, if only because it's a platform where the desktop consumer is considered worthy of optimizing the VM for.  I'm getting ahead of myself, for sure, because the Flash VM is still quite a bit slower than the Java one (and it definitely doesn't have escape analysis), though the gap is closing (when I get around to running them I'll post some current test results in another thread).

Well I don't know how serious I should take this post.
Have you ever benchmarked flash9's VM?
Sure there have been GREAT improvements compared to older versions of flash - but only because older versions of flash did not have a JIT at all.
So in fact Flash9 adds to Flash what Java has since about ... well I guess it was 1.1.7 when Sun shipped it with the Symantec Just-in-Time-compiler.

If you would have seriously benchmarked the flash-vm, you would see that it cannot compete not even with the client-vm, not speaking about the server-jvm at all.
The client-jvm does not do too fency optimizations, but has undergone major tuning over the past years - and also benefits from other runtime improvements that were done to the rest of the runtime. And the server-compiler itself generates code better than the .NET JIT without any question.

I don't know wether the tired compilers will be default anytime soon, but I think this direction is right.
A focus could be to make the client-compiler compile even faster (at the expense of the quality of the generated code), because the server-compiler will be there anyway to optimize the really hard stuff.

lg Clemens
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #19 - Posted 2008-03-08 14:59:58 »

They can be sceptical all they like - it's already implemented in Excelsior JET and it works.
Sure, the question just seems who will implement it in Java.
I see ongoing bashing of Sun for not implementing stack-allocation - but on the other side, nobody else takes the work to do it now that Java is open-source. It seems its just not important enough Wink

By the way the team that implemented initial EA and stack-allocation is located in Linz/Austria (40km away from my home) ... it seems they already did implement a prototype: http://www.usenix.org/events/vee05/full_papers/p111-kotzmann.pdf

lg Clemens
Offline ewjordan

Junior Member





« Reply #20 - Posted 2008-03-09 03:43:43 »

I'm aware that Flash's VM still can't touch Java's.  For Flash 8 there was at least a 10x performance lag versus Java when I checked; I think 9 is closer, but still quite a ways off.  So I'm not saying that the performance is there yet.  But it's getting closer, and Flash just seems like it's being developed in a much more flexible manner than Java.  The past two versions of Actionscript have each seriously broken code from the previous versions, to the point that you're essentially learning a new language.  I see absolutely no pandering to the pathetic lower 10% of programmers when design decisions are made regarding Actionscript, whereas Java's evolution is almost completely determined by the fact that too many Java programmers suck at programming to add much complexity to the language.

For instance, this whole stack allocation thing has one extremely simple solution.  Forget escape analysis, just allow classes or structs with value semantics - this has been suggested a thousand times for a thousand reasons.  If you can never pass a pointer or a reference, then BAM!, the thing can never escape, so you can safely allocate it to the stack.  Easy to implement, proven to work (built-in types prove this).  But no.  As Sun sees it, any possible means of declaring and manipulating a value type is far too complex for the rubes that program Java, so the idea gets flushed every time it's brought up.

I'm not saying this is totally a bad move on Sun's part.  It probably lessens the overall amount of whining that they hear, especially given that their installed base contains a whole lot of terrible programmers (banks are filled with them) that really would have trouble learning another syntax element or compiler hint.  But it does mean that the language becomes a haven for that type of programmer, and the rest of us have to live without certain features that would really help us.

From what I can see, Flash's performance is currently bottlenecked at the development level - they are working hard to improve, but it takes a lot of work.  They just got a JIT compiler in, so they still have a lot of catch up to do, and we have no idea how far they'll take it.  But Java's performance is quite often bound by choice, not development time.  Many of the reasons it is slower than native code could be addressed in relatively easy to implement ways, at the cost of changing pieces of the language, breaking code, or making people learn new syntax.  Which they are extremely hesitant (justifiably or otherwise) to do.  Maybe it's naive to expect Flash to ultimately win out, but unless Adobe starts pandering to their lower 10% more than they do now I don't think it's completely out of the question.
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #21 - Posted 2008-03-09 11:12:52 »

Quote
But it's getting closer, and Flash just seems like it's being developed in a much more flexible manner than Java.  The past two versions of Actionscript have each seriously broken code from the previous versions, to the point that you're essentially learning a new language.
In my opinion this just shows how bad the initial design of flash was - and where it comes from.
First it was just a thing for dynamic vector graohics, them some poor scripting was added and somehow married ith the video-design they stll had in mind.
The developers found that because flash is so widely deployed that they could make webapps with it, so again some pieces were added some where broken.
So from my point of view flash only focuses what developers are currently crying for, no matter how it would influence the "whole picture" - it may sound dynamic but in my opionion its a tradeof to produce something useable (any hypeable) for now no matter what will be tomorrow.
Very much like MS blowing up C# wih all feature developers can imagine, just to ride on the "hype-wave".
It also to some degree shows that flash is not realy used for very serious stuff, unlike java, because enterprises really don't like stuff to be broken - code has to work for decades instead of just a few versions. Take some Java-1.1 code and you stll can perfectly extend and enhance it with the current JDK/IDEs.

If you look at Java, which has been initially designed for applets and web-devices, it later evolved on the server.
It was ported to mobile devics and lately to blu-ray players ... its extremly flexible.
And on the server it did not feel like a misfit, java was perfectly capable handling the server stuff - as well as the stuff on the client (which unfourtunatly was a  bit out of SUN's focus at that time). Could you ever imagine flash would be used outside the area it was developed for?

Quote
For instance, this whole stack allocation thing has one extremely simple solution.  Forget escape analysis, just allow classes or structs with value semantics - this has been suggested a thousand times for a thousand reasons.  If you can never pass a pointer or a reference, then BAM!, the thing can never escape, so you can safely allocate it to the stack.  Easy to implement, proven to work (built-in types prove this).  But no.  As Sun sees it, any possible means of declaring and manipulating a value type is far too complex for the rubes that program Java, so the idea gets flushed every time it's brought up.
This has always been a problem point - and if you look almost no languages add that.
Value types add some kind of complexity to the system which affects _all_ developers, whereas only relativly few would really benefit a lot from them.
So ... if flash is so cool why does actionscript not have value types Wink

lg Clemens

By the way my style is a bit of .. well ... agressive so don't take any offense please
Online princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2008-03-09 11:20:02 »

I reckon value types would add vast amounts of benefit to lots of developers. The real problem is inertia in the massive JRE platform and the VM etc.

Cas Smiley

Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #23 - Posted 2008-03-09 19:38:51 »

I reckon value types would add vast amounts of benefit to lots of developers. The real problem is inertia in the massive JRE platform and the VM etc.

Most likely for game developers, not for me, nor for the server guys Wink
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #24 - Posted 2008-03-09 22:10:35 »

I don't see them solving all problems and they increase complexity for the developer while having a alternative doesn't and introducing it doesn't remove the need for escape analysis and ... and ...

I think I can even think up situations where they decrease performance.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #25 - Posted 2008-03-09 22:33:27 »

I think I can even think up situations where they decrease performance.
When used right they would be definitivly a way to improve performance, the other way round to opposite happens.
Look at C++ where you have almost all possibilities when it comes down to tell the compiler what you *really* want it to generate - it requires a lot of knowledge to keep the complexity manageable. Worst is, when available they will be used, so even the 98% that won't benefit of value types would have a hard time learning things they don't even seriously need.

lg Clemens
Offline komadori

Senior Newbie





« Reply #26 - Posted 2008-03-09 22:57:15 »

Worst is, when available they will be used, so even the 98% that won't benefit of value types would have a hard time learning things they don't even seriously need.

I'm happy for the Java programming language to serve the corporate need for large numbers of warm bodies on seats, but I wish the JVM was more flexible.

Offline DzzD
« Reply #27 - Posted 2008-03-10 01:19:50 »

Quote
...IBM article seemed to strongly advise against that type of stuff (the author all but implied that anyone that would consider it is a freaking idiot)....

lol, forget about what IBM said... they are not reallly an example in quality.... they can give advice on commercial stuff and how to sell innefficient software, but I think they cant give any advice about technical part...

Implementing your own object heap using a static array of Vec2D may be a good solution. this is always a deal on readability and efficiency... but you cant do all for readability or all for efficiency, both are wrong way.

EDIT:
I did this test for you  Wink
http://www.java-gaming.org/forums/index.php?topic=18318.0

Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #28 - Posted 2008-03-10 03:03:59 »

IBM promotes / forces its employees to write paper and articles this provides a steady stream of papers/articles of very varible quality. You have to digg for good stuff and filter out bad stuff. dismissing it all because a bundle are bad gets you on the short end.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline ewjordan

Junior Member





« Reply #29 - Posted 2008-03-10 05:47:41 »

This has always been a problem point - and if you look almost no languages add that.
Value types add some kind of complexity to the system which affects _all_ developers, whereas only relativly few would really benefit a lot from them.
So ... if flash is so cool why does actionscript not have value types Wink
I don't know that I would say almost no languages use value types - C++ and C# both have this ability, people successfully put it to good use all the time, and I don't see all the claimed negative side effects in those areas.  In languages like Python, even though you can't declare your own value types (as far as I know - I'm a bit of a Python noob, to be fair) the need for them is much reduced because of the presence of immutable tuples as a built in type (which is another potential solution with minimal learning curve and simple implementation - I'd totally shut up forever about this if these were added to Java).

Yeah, I think my ode to actionscript was probably a bit overblown - you're right, it still has all the problems of Java, and more.  I agree with the comment that most of its recent progress is largely due to its initial crappiness.  But I am hopeful that a day will come again when you can code browser-based games in Java without the current stigma of the applet (or - God forbid! - the dreaded signed applet plus security dialog, or worse, web start).
Quote
By the way my style is a bit of .. well ... agressive so don't take any offense please
None taken at all - same disclaimer here (we only argue because we care!).  I really do love Java, I prefer it to pretty much every language I've coded in, so please take anything negative I say about it with a hefty grain of salt!
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (37 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (41 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (60 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (35 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!