[gclist] Incremental collection and time limit in Boehm

wink wink@saville.com
Wed, 16 Jan 2002 19:46:51 -0800


David,

I am a little scared and don't like to change things that aren't
broken. At this time I'm exploring and the feed back I've gotten is
great.

Thanks,

Wink

---- Original Message ----
From: chase@world.std.com
To: wink@saville.com, gclist@lists.iecc.com
Subject: Re: [gclist] Incremental collection and time limit in Boehm
Date: Wed, 16 Jan 2002 14:10:37 -0500

>At 10:36 AM 1/16/2002 -0800, wink wrote:
>>Related to my previous thread with a GC on an embedded system.
>>
>>It appears that using the incremental mode and setting GC_time_limit
>>appropriately my also also be a solution to minimizing the the hit 
>GC
>>will take at any one time.
>>
>>With regards to the Boehm Collector:
>>
>>Is incremental collection and using GC_time_limit reliable?
>
>Don't know for sure.
>
>>Is it widely used?
>>
>>Is there a Boehm Collector specific email list?
>
>This is about as good as it will get.
>
>I think you should not be quite so worried about modifying
>the B-W collector.  The code that you will need to fiddle is
>well-isolated (last I checked) from the nuts and bolts of
>garbage collection.  You should be able to modify it to make
>it not stop "your threads".  In fact, this might even make
>sense as a reasonable interface to export in general, if you
>care to put that much work into it.  (A thread could, for
>instance, call something like "gc_leave_this_thread_alone()").
>Conversely, you could require that it only fiddle with
>explicitly registered threads.  In either case, the only
>gotcha that I see comes if you drop in BW gc_malloc as a
>replacement for malloc, and some library code that your
>RT code calls happens to invoke malloc.  That would be bad,
>but presumably that is typical of many things in the RT
>world.
>
>About 11 years ago (yes, it has
>been around that long) I modified it to run on Mach, and most
>of that work involved iterating over the (POSIX) threads and
>stopping all but the current thread, then fishing the stack
>bounds out for each thread.  Cross-my-heart, this was not
>tough code, and that is from my 11-years-ago, little-experience-
>with-x86 point-of-view.
>
>David Chase
>