The analysis is fine, but "escape analysis" is often conflated with stack allocation, and at this hotspot is actually really terrible. The constraints on allocating to the stack mean it happens very infrequently, even if the literal escape analysis would permit it otherwise.
Calling it 'stack allocation' is confusing - object fields are replaced with scalars in the IR. The whole object is not allocated as it would have been on the heap but on the stack in the alloca sense.
But I don't think the constraints are that bad are they? Can you give examples? Modern compilers like Graal can even scalar replace objects if they will escape in the future.
Given that the HotSpot compilers are not Graal and HotSpot's scalar replacement optimisation is notoriously fragile, I think the original statement was fair. Once Java 9 rolls around and Graal is just a plugin instead of a whole separate VM build, it'll be less fair, and if Graal ever becomes the default compiler that replaces C2 then it'll be even more fair, but I guess that is years away at best.
The biggest constraint by far is the reliance on inlining. Inter-procedural escape analysis could potentially remove the need for value types in many places, but it doesn't seem like the JVM engineers believe that's feasible.
It is not fair, because many of us do deployments in other JVMs, but people keep waving the flag Java performance == Hotspot as if e.g. C++ performance == gcc.
Ah, I meant "alternatives to HotSpot" which is what the parent was implying.
I've read the Graal papers and part of the source code. So I am familiar with PEA. It's too bad that optimisation didn't make it into C2 yet. I wonder if it ever will.
