The HotSpot engineers are constantly working on improving performance. I noticed two interesting commits recently:
Vladimir Kozlov improved Compressed Oops so that it doesn’t need to do encoding/decoding if the heap is smaller than 4GB and to reduce branches/checks if the heap is between 4GB and 32GB. The end result is that 64-bit now surpasses 32-bit performance in more situations. See my entry about Compressed Oops if you don’t know what I’m talking about. :)
Christian Thalinger added support for load unsigned in the -server JIT. This means that things like bytearray[i] & 0xFF and intarray[i] & 0xFFFFFFFF (necessary since JVM bytecode doesn’t support unsigned types) can be transformed into load unsigned operations to avoid the performance penalty. This can make a decent difference in some cases (e.g. charset operations).
Ismael Juma 
But… the unsigned variants *belong* in the Matcher! If you put them in the core optimizer, then *everyplace* there’s a reference to ‘LoadI’ or ‘LoadB’ you have to add the unsigned variants, or you’ll screw up existing optimizations.
If you’re seeing missed unsigned opportunities, the Right Thing To Do is to canonicalize the IR such that the masks end up next to the loads.
Final note: Azul engineering has been busy in the HotSpot compiler business as well, including doing a number of optimizations related to removing bogus masks.
Cliff
Architect of the Server compiler
Hi Cliff,
Thanks for the comment. I suggest sending an email to the hotspot-compiler-dev mailing list so that the people who worked on and reviewed the change can benefit from your insight (and possibly explain their reasoning). :)
Best,
Ismael
Thanks… we’re having the internal debate about whether or not to start putting stuff back to the open source HotSpot.
We’ve made a huge ton of changes; our VM is much smaller & lighter… and might be more performant on an X86. E.g. we’ve got tiered compilation turned on by default, and have had it on for over a year.
Cliff
Very interesting Cliff.
The Azul VM certainly sounds very nifty. It would certainly be nice if some stuff could be put back to the open source HotSpot, but I understand that it’s not a simple decision given business interests and such.
Regarding tiered compilation, great that you guys got that to work to the point where it could be enabled by default (and for over a year at that). I was following a similar project for HotSpot with interest, but it seems like that is stalled at the moment.
Ismael
Is the better CompressedOops by Vladimir going to be in 6u14? Or will we have to wait until u16?
The change seems to be 6791178 — I’m trying to figure out if that made it out of openjdk to the 6u14 stuff or not…
Hi Scott,
As far as I understand, the change made it into HS15 but not HS14. 6u14 is based on the latter, so I don’t expect it to be in that release (note that the matching numbers are simply a coincidence).
I don’t think Sun has announced what update release after 6u14 will include a new HotSpot, so I can’t say if 6u16 is the one.
Best,
Ismael
Hi Ismael, Regarding post 4, Azul has just started an open source project for Zing see:
http://www.azulsystems.com/press/azul-systems-announces-new-initiative-to-support-open-source-community-with-free-zing-jvm