[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: possible garbage collector problem...

> From: tribble (Eric Dean Tribble)
> I really prefer a garbage collection model that allows threds to share
> resources.  Then global optimizations can be made at runtime for
> properties of the system, and economies of scale kick in for some of
> the wierder optimization techniques.  This bias comes from imagining
> an operating system built out of a language that assumed garbage
> collection.  The system wouldn't load a different garbage collector
> for each program (imagine grep and cat with their own gc).  It would
> consider gc a system supplied function: runtime support.
> Different threads should be able have different heaps and garbage
> collectors, but it shouldn't be wired in.
> On the other side, garbage collection without migration allows us to
> have any number of heaps with negligible overhead.  I have a suspicion
> that that freedom will buy us something.

What I've been describing has the advantages of both styles.  You have
heap root structures replicated per-thread-using-a-GC, but common GC
code.  Any thread has the OPTION of using a different garbage collector
if it requires special GC behavior, or even of having multiple heaps
that run under different GCs.

The threads share a common big heap, parceled out in a chunks by a
thread whose sole job is to manage the intertask arbitration.  This
is the happy medium between:

 - common-heap, which requires intertask locking on EVERY new and
   free, and

 - heap-per-thread, which requires pre-allocation of enough heap
   to do anything the thread might need to do.

HPT chews up memory, but is fast.  CH uses minimum memory, but is
slow (and gets slower because it scatters each thread's working
set throughout VM, causing thrashing).  Chunky-shared lets you tune
the tradeoff between interthread time-loss and wasted memory.

(By the way, chunky-shared is how unix manages memory.  sbrk() is
called occasionally, to append wholesale lots of RAM to the end of
the data segment, while malloc() and free() sell and buy it at
retail from/to this local stock.)


(PS:  I bet grep has its own copy of sbrk(), malloc(), and free(),
      except on unix boxes with shared libraries... B-) )