Patch: MAXPATHLEN usage - PR21821

[Boehm, Hans]

I don't think I saw most of the gcc thread, but I'd be amazed if
stack allocating StringBuffers within libgcj caused a problem with
GC stack scanning.

The additional overhead for stack scanning per se is almost always
negligible, I think.  Per byte, it's more expensive than scanning the
heap with the gcj configuration, but there's typically very little
of it around.

The "stack holes" issue really matters only for frames that are
going to be around for a while.  I expect very few, if any, of the
libgcj
routines have that property.  My intuition is that it's good to have
short lived routines scribble anything but pointers into the stack
region; that reduces the probability of seeing leftover pointers
there later.  (I think the original thread here started in the
context of Lisp, which seems to often use much larger stacks, especially
for certain toy benchmarks.)

I would certainly go with stack allocation anyplace we can reasonably
get away with it.  It avoids the (currently still too long) allocation
sequence, improves cache behavior by not touching new memory, and
reduces GC frequency.

Hans

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org 
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of Andrew Haley
> Sent: Thursday, June 02, 2005 10:11 AM
> To: Bryce McKinlay
> Cc: tromey@redhat.com; Per Bothner; David Daney; 
> java-patches@gcc.gnu.org
> Subject: Re: Patch: MAXPATHLEN usage - PR21821
> 
> 
> Bryce McKinlay writes:
> 
>  > >Per> For CNI code it would be even better to use a 
> stack-allocated  > >Per> "RawStringBuilder" struct:  > >  > 
> >When compiling from source, gcj uses 
> gnu.gcj.runtime.StringBuffer to  > >implement String 
> concatenation; we could change it to stack allocate  > >this too.  > 
>  > A potential argument against this is that was raised 
> recently is that 
>  > stack-allocation creates more work for the GC and 
> increases the chance 
>  > of "uninitialized stack holes" where dangling pointers can 
> hide. Without 
>  > precise stack scanning, I'm not convinced that the gains 
> would be worth 
>  > it compared to potential heap bloat caused by false pointers?
> 
> That's true.  However, it would be possible to solve this 
> problem entirely by zeroing stack-allocated buffers.  From 
> what I've seen of the overhead of conservatively scanning the 
> stacks, this would probably be worthwhile.
> 
> Andrew.
>