Lew said:
That is a feature that Java should have. I would say, rather, compounds
of compile-time constants, or even more relaxed, compounds of final
variables.
I think to be viable the compounds would have to specifically allow
non-final variables. Something like this:
Type stuff = class Type {
int len;
int id;
};
fill( stuff );
// ...
private static fill( Type filler ) {
filler.len = 2;
filler.id = 42;
}
Ought to be a prime candidate for being kept on the stack rather than
allocated in the heap.
Where I find this applicable is something like this
int i = 42;
String s = String.toString( i );
// do something with s...
public class String {
public String toString( int i ) {
char[] c = new char[11];
int len; // of string
// fill c and set len
return new String( c, 0, len );
}
}
Which is similar to what the Java library does now. All of the objects
above should be strong candidates for some sort of "return optimization"
and kept on the stack. Strings don't happen to be mutable but that's
immaterial to the stack vs. heap discussion.
If you look back to post we had here about a year ago, on why Java was
so much slower than C when writing to a stream, that's the modification
I eventually made to make Java actually beat C (on our systems anyway,
not the OP's). Don't allocate objects on the heap each time through the
print loop, allow for one single mutable object that gets reused. A
stack-based object would simulate that mutable object really well,
probably better in terms of optimization and speed.
I think some return optimization of this sort could really speed a lot
of leaf methods up in Java.
That bad bit of this, I think, is that modern CPUs have relatively small
caches on their stacks. Small cache means having to fetch from main
memory on a cache miss (or if it fills) so that'll slow you down if you
try to push huge structures onto the stack. Maybe this isn't such a
great idea and we need to think about how to make heap memory allocation
faster to reduce the penalty for a "new" close to 0.
V