Re: GCJ 3.3 LEAKS Throwable & Derived Classes

["Craig A. Vanderborgh" <craigv at voxware dot com>]

Andrew Haley wrote:

> Andrew Haley writes:
> > 
> >  > Who would've thought?  Our VXML browser application, and our port
> >  > of Jetty make strategic use of static linking to limit the immense
> >  > libgcj library to only what's actually used by each application,
> >  > resulting in a rather large reduction in the size of the
> >  > executables.  It's an unexpectedly useful and practical approach.
> >  > Too bad static linking doesn't work w/gcj 4.x.
> > 
> > It works for me.  As far as I can see your current problem is to do
> > with NPTL, not gcj.  Did you read the mails you were sent?
>
> Sorry, I mean linuxthreads.  I really did try to duplicate your
> problem as soon as you mentioned it.
>
> Andrew.
>
>  
Hello Andrew,

I just ran another test to try to track this problem down a little 
better.  The test platform was RHEL 4, which has NPTL threads, I 
believe.  I built gcc-3.3.6 for RHEL 4, installed it and used it to 
rerun the testcase.  But maybe glibc still uses NPTL??

ANYWAY, the problem is reduced, but is still present.  To get my test 
program to run with stable memory usage, all you have to do is replace 
the allocation of Exception/Throwable with something not derived from 
Throwable, say Object.  When you do this, the leaking problem completely 
goes away.

So what is the domain of this problem, and why do you think it has 
something to do with NPTL?  And does GC treat Throwable-derived classes 
differently?  Is "_Jv_MarkObj" (boehm.cc) called for ALL objects, 
Throwable included?  Or is Throwable handled differently in some 
way(s)?  And do expect that I am seeing a C leak from some native code, 
or do you think that it's some GC related issue?

We're a little needy right now, but we really are going down in flames 
over this.  Please toss me a line if you possibly can.  Just answering 
these questions so I can begin to understand the problem would be a 
really big help.

Regards,
craig