RE: [Caml-list] OCaml GC [was Is OCaml fast?]

[Jon Harrop <jonathandeanharrop@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]

I don't understand why this would help here though. Wouldn't that help when
a long-lived structure was single large block but, in this case, the
long-lived structure is a tree composed of many small heap-allocated blocks
and, therefore, they would undergo the same wasteful "allocate in young only
to be copied to old" pathological behaviour?

 

Surely what you really want the ability to spot when a full minor heap
contains mostly live objects and, therefore, make the whole minor heap part
of the major heap, allocate yourself a new minor heap and clear the
remembered sets. IIRC, G1 does something like this.

 

On a related note, When designing HLVM I thought that a mallocs function
that allocated many small blocks of the same size such that they could be
freed individually would be helpful. Another option might be to preallocate
larger numbers of blocks at the same time under the assumption that a thread
allocating many small surviving blocks would continue to do so, as a kind of
pool hybrid.

 

Cheers,

Jon.

 

From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Eray Ozkural
Sent: 28 November 2010 18:57
To: Benedikt Meurer
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OCaml GC [was Is OCaml fast?]

 

On Sun, Nov 28, 2010 at 4:29 PM, Benedikt Meurer
<benedikt.meurer@googlemail.com> wrote:

Speaking of the OCaml GC in general, wouldn't it make sense to replace the
current generational collector with a collector framework that requires less
copying in the common case. For example, dividing the heap into two parts,
"large object space" and "small object space", where LOS is managed by
mark-sweep/mark-compact (could use the current major heap) and SOS is
managed by a recent mark-copy/mark-region collector (Immix [1] comes to mind
here). That way objects would no longer need to be copied between
generations, and using Immix may also reduce cache misses and improve
locality of small/medium sized objects (with proper evacuation heuristics).
This should be doable with a moderate amount of work, and should require no
incompatible changes, while opening the door for concurrent/parallel garbage
collection (this would require incompatible changes then, replacing
caml_young_ptr/caml_young_limit with TLS vars, etc.).

Benedikt

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.144.3640


I was suggesting dealing with small fixed-size objects differently in
another post. This doesn't sound like a bad combination, nice idea :)
 
Best,


-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct


[-- Attachment #2: Type: text/html, Size: 6452 bytes --]