[Gc] Re: Boehm update in GCC

Andrew Haley aph at redhat.com
Mon Apr 18 11:25:45 PDT 2011

On 04/16/2011 11:47 AM, Ivan Maidanski wrote:
> Hi Andrew,
> Mon, 11 Apr 2011 08:28:06 +0100 Andrew Haley <aph at redhat.com>:
>> On 10/04/11 18:47, Ivan Maidanski wrote:
>>> Hi,
>>> I've reviewed the patches from gcc/boem-gc. The following ones I'm unable to
>> process (and some at GCC side should have a look at, may be the original patch
>> authors could adopt their ones for GC v7+):
>>> bgc-167681 - darwin-specific (probably this one no longer needed for v7+);
>>> bgc-171516 - testsuite-specific;
>>> bgc-144045 bgc-150269 bgc-151013 bgc-151627 bgc-166028 - scripts-specific
>> ones;
>>> bgc-114869, bgc-124081 - specific to thread suspension.
>>> The rest ones are either already applied or obsolete.
>>> The open question is whether it will be possible to use completely
>>> unmodified BDWGC in GCC (to simplify further updates). Of course, it
>>> will require modification of boehm.cc in GCJ.
>> I'll do that, but can you give me any idea what sort of changes are needed?
> Here's the list:
> 1. check GC_[un]register_my_thread, GC_get_stack_base prototypes (the arguments might be different from gcc/boehm-gc);
> 2. gc_local_alloc.h is removed (GC_REDIRECT_TO_LOCAL has no effect);
> 3. GC_en/disable() are declared in gc.h;
> 4. GC_PTR should be replaced with "void*";
> 5. GC_finalize_all - now it invokes finalizers instead of calling finalizer notifier (so, GC_finalize_all should be called from a separate Java thread);
> 6. GC_get_heap_size and GC_get_free_bytes are now synchronized (so the client shouldn't call them with the alloc lock held);
> 7. GC_set_free_space_divisor now returns nothing (use GC_get_free_space_divisor);
> 8. GC_all_interior_pointers should now be manipulated via GC_get/set_all_interior_pointers() (same for GC_oom_fn, GC_java_finalization, GC_finalize_on_demand, GC_finalizer_notifier);
> 9. GC_suspend/resume_thread, GC_is_thread_suspended are missing - this the most hard thing to change (java thread suspension should be implemented w/o using pthread_suspend/resume, eg. it could be implemented via cond_signal/wait).

Oh my, that's a lot more than I was expecting.  :-(


More information about the Gc mailing list