alloca and native code

[Boehm, Hans]

Should there be an explicit deallocation hint in the GC interface?  If the
array is of significant size (greater than about 100 bytes), it would
probably be cheaper to deallocate it explicitly on function exit.  If it
stays around for a long time that's probably even cheaper than alloca, since
it avoids scanning it.

It may be that not all future garbage collectors will support explicit
deallocation, but the current one does.

Hans

> -----Original Message-----
> From: Andrew Haley [ mailto:aph@redhat.com ]
> Sent: Tuesday, September 12, 2000 11:18 AM
> To: tromey@cygnus.com
> Cc: Oskar Liljeblad; java-discuss@sourceware.cygnus.com
> Subject: Re: alloca and native code
> 
> 
> Tom Tromey writes:
>  > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
>  > 
>  > Andrew> It would be nice if we didn't do this in embedded systems,
>  > Andrew> since it breaks the nice property that Java aprograms have
>  > Andrew> small stacks, and the stack is only scanned conservatively.
>  > Andrew> We ought to question if this is a performance win on any
>  > Andrew> system.
>  > 
>  > I usually do it because it is more convenient than doing 
> an explicit
>  > alloc/free of unscanned memory (eg using _Jv_Malloc).
> 
> Yeah, but if you do this you aren't gettting unscanned memory, so this
> is rather deceptive.  
> 
> 
>  > In general I only use alloca or a variable array if the size is
>  > bounded (though that probably isn't always true, sigh).  But I
>  > agree that revisiting this makes sense.  Maybe we should enter a
>  > PR, or even make it part of our "coding standard (if we had one)".
> 
> IMO a coding standard would say "in native methods, don't use stack
> space for arrays.  Howver, short strings are acceptable."
> 
> Andrew.
>