=?koi8-r?Q?Re=3A_[Gc]_Questions_on_boehm-gc, _fragmentation, _and_low_memory_resources?=

Ivan Maidanski ivmai at mail.ru
Wed Jul 8 11:28:25 PDT 2009


Yann Frach <yann.frach at gmail.com> wrote:
> Hi,
> I'm working on embedded devices with low memory and I'm worried about
> heap fragmentation
> in a non-moving GC like boehm-gc. I have a few questions.
> - Does boehm-gc do something to avoid/minimize fragmentation ?

BDWGC maintains separate list for small free objects (I guess, a typical malloc implementation deals the things in the same way).

> - Is there any "moving"/compacting implementation of boehm gc, and if
> not, would it be possible ?

BDWGC manipulates/returns direct pointers to object (and it is conservative), so it's not possible to move an object while it's alive.

> - For people with experience in the embedded context, is it worthwhile to use
> boehm-gc and how do you make it work as good as possible ?

Well, what are your alternatives? It depends on your needs...
There are proprietary GC's for embedded targets but most (if not all) of them are tightly integrated to a VM.

For my project, I've developed a small alternative to BDWGC which has the same ABI (a small subset of it sufficient for java/gcj-like functionality) but different implementation. My priority was small code size (which starts from 3.5K), small internal data overhead size and portability (not allocation/collection speed). It does no automatic registration r blacklisting, nor it implements any of "advanced" BoehmGC allocation/collection algorithms. It doesn't deal with fragmentation at all as it relies on the standard malloc/free (i.e. GC_malloc(size) calls underlying malloc with the same size arg and unreachable objects are returned to the underlying system thru free()). I know that this decision has some drawbacks but since it has the same API, it serves me as a quick/temp replacement of BoehmGC where appropriate.
I'm planning to have it's public release soon (while I'm still hoping to see my BDWGC pending patches (regarding it's API at least) either committed or rejected before the event).

> Thanks for your thoughts (and possibly pointers on more information) on this.
> Regards,
> YF


More information about the Gc mailing list