This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: Patch: MAXPATHLEN usage - PR21821
- From: Andrew Haley <aph at redhat dot com>
- To: "Boehm, Hans" <hans dot boehm at hp dot com>
- Cc: "Bryce McKinlay" <mckinlay at redhat dot com>, <tromey at redhat dot com>, "Per Bothner" <per at bothner dot com>, "David Daney" <ddaney at avtrex dot com>, <java-patches at gcc dot gnu dot org>
- Date: Thu, 2 Jun 2005 18:57:42 +0100
- Subject: RE: Patch: MAXPATHLEN usage - PR21821
- References: <65953E8166311641A685BDF71D8658262B6FE0@cacexc12.americas.cpqcorp.net>
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.