Stack Allocation RFE needs your vote

General Discussions
#1

Java should support the creation of objects on the stack. A RFE has been submitted in this sense and needs your vote: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6336351

The problem is simple, and can be illustrated by the following (from JScience benchmark at http://jscience.org):

Matrix and Matrix versus non-parameterized matrix (double)
Non-parameterized matrix (double based) 500x500 multiplication: 3.940 s
Matrix 500x500 multiplication: 25.10 s
Matrix 500x500 multiplication: 28.43 s

Parameterization is great, but who is going to use it if there is there such penality when creating new objects!
This is a serious performance issue…that stack allocation would solve nicely.

By the way the parameterized matrix here uses Javolution (http://javolution.org) pool context for row-column multiplication here, unfortunately the overhead of this “soft” solution is significant for small objects; still without it you would get execution time around 1 min !!!

This could be BIG for games developpers, please cast your vote at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6336351

One possible implementation (very fast) would be that when you assign a stack object to an object out of the stack you always do a copy (cascading to members on the stack) . Then, resetting the stack is immediat and does not require any kind of gc (no object outside the stack has reference to stack objects) :slight_smile:

In practice, for the developer, it means that objects created while on a stack are “values objects” (manipulated by copy not by reference) they might even be identified by a new interface (e.g. java.lang.Copyable) to avoid problems in case @stack is used at the wrong place (a concern for many it seems).

#2

As much as I like the simplicity and speed of stack allocation in C++, I can’t say I see how they’d work well in Java. Part of the ease with Java is not caring about such stuff. If you really want stack allocated objects then why not switch to C#, which has this (and as a result ends up looking a right mess at times).

#3

Most people will care about stack allocation only when implementing low-level methods for which performance is crucial and creating objects on the heap would result to in a significant drop of performance (5x-10x).

#4

Most people won’t care once escape analysis makes it into the JVM.

Cas :slight_smile:

#5

Exactly! People should not support this RFE since escape analysis is a better, simpler, cleaner and potentially faster solution

#6

As far as I know Escape analysis does stack based allocation.
Couldn’t EA be used to offload small but long lived objects onto the heap as well as short lived objects?

#7

Small but long lived objects already go on the heap :wink:

Cas :slight_smile:

#8

Sorry, I meant stack in my sentence and not heap. :slight_smile:

#9

EA doesn’t dictate how long something stays on the stack for. It may stay on the stack practically forever if it never escapes (meaning effectively the function call never returns).

Cas :slight_smile:

#10

I rather doubt that escape analysis on its own would make much impact on the performance of this type of problem. It would help with computations involving individual Complex values but rather less (if at all) with 500x500 matrices of them. Obtaining reasonable performance for the latter case is likely to be beyond compiler technology for the forseeable future, at least without some kind of additional information from the language. Personally I think immutable types (which have value semantics and do not support reference equality) is the preferable solution. However as the problem only applies to rather small proportion of the Java community I am not optimistic.