Patch: MAXPATHLEN usage - PR21821

[Andrew Haley]

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.