On 12/01/2010 02:31 AM, Charles Oliver Nutter wrote:
On Tue, Nov 30, 2010 at 5:59 PM, Rémi Forax<[email protected]> wrote:
You're right.
But in that case, you always execute the same code.
So your runtime should do the stack allocation
i.e use int instead of Integer.
Well the case I'm interested in is for heap-based local variables. If
it were possible to stack-allocate closures, their cost would be
drastically reduced, and cache locality for those variables would be
as good as other variables on the stack. As it stands, they not only
have to be allocated as normal heap objects, they also bump the TLAB
and almost certainly escape, preventing EA.
- Charlie
If you can stack-allocate a closure. Your closure don't escape.
So your runtime should be able to know if a closure escape or not
and if it doesn't escape, you can generate the bytecode from
where you create the closure to where you use it.
5.times { |i| puts i }
is transformed to
for(int i=0; i<5; i++) {
puts(i);
}
here 'i' is is now stack allocated.
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
