can an object be allocated on the stack?

[Thomas Wuerthinger]

We are thinking about support for this in Truffle where the language implementor can specify stack-allocated objects (and is himself responsible for the safety of the feature). The first such candidate would be the Arguments object that is allocated and passed to each guest language call. Currently, we however do not perceive enough negative performance impact from heap-allocating those short-lived objects. There are lower hanging fruits ;). - thomas

On Jul 30, 2013, at 12:55 PM, Lukas Stadler <lukas.stadler at jku.at> wrote:

> At the moment, we do not do this optimization.
> I'ts not really a question of support in Graal (it would be rather easy to support in the compiler, because the necessary primitives are there), it's more a question of support in the VM.
> We want to keep our native code delta to HotSpot small, and this would need extensive changes to the gc and debug infrastructure.
> 
> - Lukas
> 
> On Jul 30, 2013, at 6:00 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:
> 
>> 
>> Sometimes it's safe to allocate an object on the stack, for example for the cases covered in Ch. 5 of http://ssw.jku.at/Research/Papers/Ko05b/
>> 
>> Can the Graal IR express such code idioms?
>> 
>> (I guess not, because if so then it would be possible to have a method return a struct, ie just let the caller allocate it on the stack and have the callee modify it via address + offset, the callee itself may be void-returning).
>> 
>> Or is it?
>> 
>> 
>> Miguel
>> http://magarciaepfl.github.io/scala/
>> 
>> --
>> Miguel Garcia
>> Swiss Federal Institute of Technology
>> EPFL - IC - LAMP1 - INR 328 - Station 14
>> CH-1015 Lausanne - Switzerland
>> http://lamp.epfl.ch/~magarcia/
>