[Gc] GC7.0 Release problem [HACKED]

Boehm, Hans hans.boehm at hp.com
Mon Jul 23 14:43:42 PDT 2007


I checked the attached patch into the CVS tree.

This should fix:

1) Cygwin if the GC is in a dll, but no dll data actually needs to be
scanned.  The code to trace from dll roots still isn't there.
2) The deadlock caused by calling Windows malloc with the world stopped.
3) Partially, the issue below.  All the initialization work is now done
in GC_init_inner.  This works, since the 7.0 collector no longer acquire
locks until a second thread is created.  And thread creationshould force
collector initialization.  Thus GC_init_inner should actually never be
called with the allocation lock held.  I suspect there is a remaining
issue, in that it's more expensive to do the allocation check in the
thread local allocation routine.  Currently GC_malloc (unlike
GC_malloc_uncollectable) only does the initialization check with malloc
redirection, or if thread local allocation is disabled.  I'm wondering
whether this was a mistake.

Since I haven't reproduced the last two problems locally, I'd appreciate
confirmation that this actually helps.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Christophe Meessen
> Sent: Saturday, July 07, 2007 5:51 AM
> To: Gc at napali.hpl.hp.com
> Subject: Re: [Gc] GC7.0 Release problem [HACKED]
> 
> The problem is not related to local stoage but to an 
> initialization problem.
> 
> GC_init_inner gets called instead of GC_init. This is because 
> C++ allocate some blocks in its initialization phase before 
> main is called.
> In my case GC_malloc_uncollectable was called before GC was 
> initialized.
> This call checks if GC is initialized and if not it calls 
> GC_init_inner.
> GC_init_inner sets the flag that GC is initialized but it 
> does not initialize the critical section. This is done in 
> GC_init that calls GC_init_inner.
> 
> When GC_INIT is called in main, it then does nothing because 
> the flag tells it that it is already initialized. So the 
> critical section is not initialized.
> The hack I did was to add the following instruction in front 
> of GC_malloc_uncollectable.
> 
>     if (!GC_is_initialized) GC_init();
> 
> There are a few other places where GC_init_inner is called 
> instead of GC_init. This problem shows up only with windows 
> because of the window specific code in GC_init. If the above 
> instruction is added, the later equivalent test and call to 
> GC_init_inner should be removed.
> 
> It would be preferable to put this instruction in front of 
> all gc calls and then get rid of the GC_INIT call in the main routine.
> 
> With this hack my code now runs in release and debug mode.
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 072307diffs
Type: application/octet-stream
Size: 10271 bytes
Desc: 072307diffs
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20070723/10a12a8d/072307diffs.obj


More information about the Gc mailing list