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).

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).

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?

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.

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?

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...

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.

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

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)

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...).

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.

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.

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

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.

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

lg Clemens

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

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.

...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.

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.

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

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!

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