so I looked at the Release Notes of JDK 6u14, but Im honestly not that mush of a ‘pro’ to get it all =P
so my eye didn’t spotted anything interesting regarding game development
did yours ?
Stability, some speed and a lot of bug fixes. Nothing major for game developers unless the speed increase is big (no numbers are stated).
Interesting feature on blacklisting apps.
Yeah the blacklist seems interesting, there doesn’t appear to be a blacklists file with this release though or am I wrong?
The “new” garbage collector is also available in this release for anyone to try it out.
// Json
Is this
not of interest?
Who wants to make a benchmark?
I don’t know what may have changed since the earlier 6u14 versions, but I did install one of those betas to test JBox2d against, since it’s tends to get bottlenecked on the small objects (vectors) created in large scenes.
And…it definitely seemed like it did something. Maybe a 10-15% speed increase, something like that. Which is pretty good, considering all the low-hanging fruit has already been plucked in the engine (essentially doing the manual equivalent of scalar replacement in the code).
What I really should do is compared an earlier version of JBox2d, one without any of that stuff done yet, and see how escape analysis does on that compared to the hand optimizations. The several rounds of manual cleanup, just blindly inlining small object allocations at the bottlenecks, gave about a 5x speedup, so runtime was quite bound in allocation/gc. I’d be real interested to see how much of that stuff this algorithm is able to pick off, I’d think it should do well since a lot of those cases were extremely easy to do by hand.
If you look at the actual buglist, getting escape analysis up to speed was really one of the major tasks for this release. Which I’m really glad to see, I was getting worried a few versions back when there were indications that it was just going to remain an experimental feature that wouldn’t be developed very far. Let’s hope it eventually gets in as a default option…
The latter was already there(and quite effective if I recall, thought some of it was already integrated into ‘normal mode’). The first bit seems newish. try searching the forum.
Stack allocation wasn’t there before. Is it in u14?
Cas 
afaik no. “Only” escape analysis driven auto vectorisation scalar replacement of small objects (and the concurrency optimisations).
That pretty much is stack allocation though?
Cas
sorry i mixed up things, it was scalar replacement not auto vectorization.
this presentation begining with slide 35 talks about scalar replacement (and all other new features)
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5427&yr=2009&track=javase
Lets see if I understand you guys right:
this is perpendicular to stack allocation - it is simply dumping that which is encapsulated by the object into the method and then removes the object from ‘play’. effectively eliminating object creation and thus removing the need to allocate anything: on the stack, heap or otherwise.
Or differently put it’s akin to method inlining except for whole classes.
But if that is so aren’t those ‘fields who are turned into local variables’ easy enough for the very limited/trivial stack allocation support that is already present?