JDK-6336351 : Stack allocations
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0,9,10
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2005-10-13
  • Updated: 2019-10-12
  • Resolved: 2017-02-16
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Object creation is still time consuming. Especially for large immutable objects (e.g. adding immutable large integers can be 8x faster when the objects are transparently recycled, ref. JScience benchmark: http://jscience.org/doc/benchmark.html

JUSTIFICATION :
Escape analysis has several limitation. It has to be very conservative at compile time and  time consuming at run-time.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
What I propose is that when a thread execute within a specified context (e.g. PoolContext) objects created with "new" keyword are allocated on the stack. The stack is reset when the thread exits the stack context except for objects which are referenced from outside the stack (e.g. static). Those can be copied (or better moved) outside of the stack by the vm.
This approach has been implemented by  the Javolution library :http://javolution.org/api/javolution/realtime/package-summary.html#OVERVIEW).

But,  having direct vm support would make the whole process:
- Faster: Stacks/pools held by the thread object.
- Easier: <i>new</i> keyword instead of object factories.
- Safer:  Export/preserve done automatically by the compiler  (e.g. assigning to a static member would result in preserve  being called).

ACTUAL -
The actual behavior is quite slow  for large objects allocations.

---------- BEGIN SOURCE ----------
A possible course of action would be first to include the Javolution real-time package to Java standard distribution. And then, integrate more and more feature to the JVM.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use Javolution PoolContext.

Comments
This doesn't target compilers as such it wants stack allocation in the Java language/platform - which the compilers would have to support. This is an ancient RFE and we have not accepted major platform RFEs through the bug system for a few years now. This should have been closed years ago but as a P5 was likely under-the-radar.
17-02-2017

It is for C2. Close it - it is a lot of efforts and Graal has partial EA which address some of these issues.
16-02-2017

Which compiler does this enhancement target?
16-02-2017

EVALUATION This RFE is being investigated for Dolphin.
10-12-2005