4

Are the rules for stack allocation optimization less strict for HotSpot Java 9-13 ?

In Java 7 & Java 8 HotSpot stack allocation of objects (due to JVM optimization known as scalar object replacement) is possible but to achieve garbage free allocation on the thread stack a number of strict constraints must be fulfilled.

The rules to enable stack allocation optimization for Java 8 (HotSpot, OpenJDK 8) are summarized in splendid answer to this question: When can Hotspot allocate objects on the stack? and as for Java 7 here: Eligibility for escape analysis / stack allocation with Java 7

In this question I would like to find out what is the current state of EA & stack allocation optimization in newer JDK version ? Does other Java VMs (eg. OpenJ9) has different rules ?

digital_infinity
  • 534
  • 6
  • 20
  • 3
    From the linked answer: “*Another important thing to know is that Hotspot **does not actually implement stack allocation of objects**. Instead it implements scalar replacement,…*” The term “stack allocation” is misleading regarding the actual purpose of this optimization. So there are no significant changes in recent JVMs, simply because putting objects on the stack never was the goal. – Holger Sep 26 '19 at 09:35
  • @Holger yeah I know that it is a JVM optimization technique not something that is language build-in feature. Maybe when ValueTypes are introduced in Java we will have a possibility to allocate complex types on the stack. Having read your comment I am adding explicite "optimization" word in the question title. – digital_infinity Sep 26 '19 at 10:05
  • 1
    That wasn’t my point. Hotspot does *scalar replacement*, which allows to treat the fields of temporary objects like local variables, enabling subsequent optimizations, like constant folding, partial redundancy elimination, strength reduction, dead code elimination, register allocation, and so on. So field values may end up on the stack if neither eliminated nor assigned to a register, but that’s not the primary goal. So scalar replacement is not applied to a broader set of scenarios, because only those allowing the subsequent code optimizations really matter. – Holger Sep 26 '19 at 14:09
  • But if temporary object has nested another object (even if it is also temporary) the scalar replacement does not work in HotSpot JVM 8. This is noted in one of the restrictions in linked questions. – digital_infinity Sep 26 '19 at 20:59
  • For example I would like to know if anything improved recently in JVM with sensing EA whether nested temporary object could be "flatten" by scalar replacement too. – digital_infinity Sep 26 '19 at 21:12
  • 1
    @digital_infinity you could try, of course, with a few flags on the VM and see the output. But C2 where this happens is very "old" compiler, I doubt much has changed... The more interesting part would be to try against Graal's C2. – Eugene Sep 30 '19 at 02:31

0 Answers0