RE: Re: Application (GC) stuck in "_Jv_MarkArray" when doing "klass->getName();"

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

You somehow want to move the getName call out of the collector.  Calling
it from GC_dump() or a partial clone, and then calling that from a
debugger or the client code should work.  Just printing klass and then
using a debugger to perform the getName() call should also work.  As
should dumping the klass values into a static buffer, and then later
traversing it and performing the getName call.

The problem is that the collector isn't designed to allocate
garbage-collected memory while you're in the middle of the garbage
collector, particularly in non-incremental mode.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Martin Egholm Nielsen
> Sent: Monday, March 20, 2006 4:21 AM
> To: java@gcc.gnu.org
> Subject: Re: Application (GC) stuck in "_Jv_MarkArray" when 
> doing "klass->getName();"
> 
> >> I haven't checked, but I'd be suspicious that getName allocates 
> >> memory, which acquires the GC lock, which is already held 
> by the same thread.
> >> (This is a non-reentrant lock.  Which is good, because 
> things would 
> >> fail in more complex ways if it weren't.)
> > Well, going into getName seems to trace furhter to 
> "_Jv_AllocString" 
> > using "_Jv_AllocPtrFreeObj" or "_Jv_AllocPtrFreeObject" 
> depending on 
> > the state of "ENABLE_JVMPI". However, now things get deep 
> for me - at 
> > least at my current state of knowledge...
> > So I don't really know where that leaves the question regarding the 
> > non-reentrant lock... :-)
> But if this is indeed a matter of locking, what other means 
> do I have at that point (_Jv_MarkArray) to identify what the 
> array is actually about?
> 
> // Martin
> 
> >> On Sat, 18 Mar 2006, Martin Egholm Nielsen wrote:
> >>
> >>> Hi there,
> >>>
> >>> In my long and tiresome (for the rest of you) attempts to 
> understand 
> >>> the doubling of my GC-times, I've now added some output 
> to "_Jv_MarkArray"
> >>> to get an idea of what and why there is suddenly an array 
> given of 
> >>> length 170.000.
> >>> (This attempt is a consequence of calling "gcj_describe_type_fn" 
> >>> from the GC, but it just halted.) So I added parts of the 
> the code 
> >>> from "gcj_describe_type_fn" into
> >>> _Jv_MarkArray:
> >>>
> >>>   if ( klass ) {
> >>>       printf( "MEN: 1\n" );
> >>>       jstring name = klass -> getName();
> >>>       printf( "MEN: 2\n" );
> >>>   } // if
> >>>
> >>> However, when the GC gets to it, "1" is printed, "2" is 
> not, and the 
> >>> GC is stuck in between.
> >>> Anyone can tell me why this is not "allowed"/fails?
> >>>
> >>> BR,
> >>>  Martin Egholm
> >>>
> >>>
> >>
> >>
> > 
> > 
> 
>