Hacker News Reader

Comment by chrisseaton | Hacker News Reader

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.

View on HN

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.

Hot spot is based on a relatively old paper at this point from what I remember and there are alternatives which purportedly perform better.

Can you name one?

Partial escape analysis is one http://www.ssw.uni-linz.ac.at/Research/Papers/Stadler14/Stad...

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.

Someone told me that Zing also does PEA, but I don't know that to be a fact.

Oh and I think JRockit might have done it as well.

Reply on news.ycombinator.com