RE: Patch: MAXPATHLEN usage - PR21821

["Boehm, Hans" <hans dot boehm at hp dot com>]

That's interesting.

I think it argues that routines that are likely to block for
long periods (call functions that do) should avoid creating
stack holes (or clear them, or let the GC know about them).

But if I understand this correctly, for most libgcj internal
uses of StringBuffer, this still shouldn't be an issue, since
I wouldn't expect most of these methods to block for extended
periods.

For routines that might block, it might make sense to stack
allocate the original buffer, which can usually be cleared
with one or two store instructions, and then heap allocate the
expansions.

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:58 AM
> To: Boehm, Hans
> Cc: Bryce McKinlay; tromey@redhat.com; Per Bothner; David 
> Daney; java-patches@gcc.gnu.org
> Subject: RE: Patch: MAXPATHLEN usage - PR21821
> 
> 
> Boehm, Hans writes:
>  > 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've certainly observed it.  When a method exits and then the 
> thread waits for a lock, the routine that waits for the lock 
> has holes in its stack, and this can keep alive the "dead" 
> references forever.  I've seen this happen, and I doubt that 
> it's an uncommon scenario.  I suspect this is reproducible every time.
> 
> Andrew.
>