JDK-4809540 : RFE: permit allocation of new objects on stack
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2003-01-28
  • Updated: 2011-10-31
  • Resolved: 2011-10-31
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Name: rmT116609			Date: 01/28/2003


A DESCRIPTION OF THE PROBLEM :
In java, most particularly in GUI programming, one frequently allocates large numbers of small objects which are only used in a local scope. The new garbage collection algorithm goes a considerable way toward solving the performance problems associated with this. However, perhaps the language could support allocating variables on the call stack, perhaps implemented internally with another stack parallel to the call stack.

I suggest:

1) That allocation on stack be introduced by adding the "transient" modifier to the "new" keyword

Object foo = new transient Bar();

2) That it be a *run-time* error to assign a transient reference to an instance variable

3) That it be possible to mark classes at compile time as not accepting transient references as method arguments. This prevents existing libraries being broken by being passed arguments that will throw exceptions that existing
code does not expect.

(Review ID: 180494) 
======================================================================

Comments
EVALUATION Related issues have come up in the past. This is clearly a non-issue for GUI programs - GUI performance problems are elsewhere. However, there are applications where recognizing and reducing allocation is crucial. The situations that this proposal addresses can likely be solved by improved implementation techniques. Supporting this in the language would encourage premature optimization and brittle APIs, and make Java a lower level language than it is today. There have been broader suggestions that require further study. I don't expect the language to change as suggested by this particular proposal any time soon. ###@###.### 2003-01-28 Unfortunately, it's not that simple. The constructor, for example, might leak the reference. Or any method called on the object might do so. The correct and safe way to do this is in the VM, which can perform escape analysis to determine which objects can be stack allocated. The author of this bug report appears to be assuming that will perform better than modern garbage collectors. That's not clear. ###@###.### 2003-01-28
28-01-2003