Re[6]: [PATCH] Re: Found? Re: [Gc] Assertion failure in GC_malloc_uncollectabl

Ivan Maidanski ivmai at mail.ru
Wed May 16 02:39:08 PDT 2012


Hi Hans,

I've committed the fix (exactly the change as you said) to GC v7.3alpha3. (I think later (although I'm not sure right now) to replace GC_generic_malloc call with GC_generic_malloc_internal one in GC_malloc_uncollectable to avoid locking twice.)

But v7.2 should also be fixed - please consult me with the versioning: it should be something like v7.2.1 but not some alpha.

Regards.

Wed, 16 May 2012 05:47:08 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> I'd be inclined just to make the offending assertion contingent on the absence of threads.  It seems to me that aside from the assertion, the code does the right thing, no matter what.  If a GC intervened, setting the mark bit to and setting n_marks to 1 (not incrementing) should do exactly the right thing.  We're holding a reference, which should be marked, and n_marks should be exactly one.  GC_malloc_atomic_uncollectable() clearly does need the same treatment, as you pointed out.
> 
> Jan's fix should also work, but cluttering GC_generic_malloc() with the details of UNCOLLECTABLE and AUNCOLLECTABLE seems less desirable to me.  Since these are large blocks, I think the small performance win in Jan's solution doesn't matter much.
> 
> Hans
> 
> > -----Original Message-----
> > From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> > On Behalf Of Ivan Maidanski
> > Sent: Tuesday, May 15, 2012 3:40 AM
> > To: Jan Wielemaker
> > Cc: gc at linux.hpl.hp.com
> > Subject: Re[4]: [PATCH] Re: Found? Re: [Gc] Assertion failure in
> > GC_malloc_uncollectabl
> > 
> > Hi Jan,
> > 
> > I'll spend more for this bug some days later and select the way to fix
> > it.
> > 
> > Regards.
> > 
> > Tue, 15 May 2012 12:00:52 +0200 Jan Wielemaker <J.Wielemaker at vu.nl>:
> > > On 05/15/2012 11:21 AM, Ivan Maidanski wrote:
> > > >> My motivation to move this into GC_malloc_generic() was twofold:
> > > >> clearly
> > > >>> GC can come in between and it seems a waste to acquire the lock
> > > >>> twice for a single operation with only a few unlocked
> > > >>> instructions in between.
> > >
> > > > I understand. But, the other alternative is to use lock-less
> > > > GC_generic_malloc_internal (not sure right now that its
> > functionality
> > > > is the same as GC_generic_malloc).
> > >
> > > I leave that decision to the experts.  I'm happy to test.
> > >
> > > > BTW. We should also fix GC_malloc_atomic_uncollectable.
> > >
> > > Looks like it is doing the same thing.
> > >
> > > Thanks for looking into this.  I still like to run with gc assertions
> > > enabled as long as I'm developing.
> > >
> > > 		--- Jan
> > >
> > >
> > > _______________________________________________
> > > Gc mailing list
> > > Gc at linux.hpl.hp.com
> > > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> > >
> > 
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list