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 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