Le 27/11/10 22:11, Pierre Etchemaïté a écrit :
> Le Mon, 22 Nov 2010 20:33:34 +0200, Török Edwin <edwintorok@gmail.com> a écrit :
>
>> Not sure what the max should be for the minor heap increase, but based
>> on this benchmark increasing size of minor heap never slows down the
>> program. Even when size of minor heap exceeds what fits in the cache.
>> I guess there is another microbenchmark that can show the opposite
>> though.
> Another consequence of increasing minor heap size is the latency
> introduced by minor heap collections. That said, when does it become
> the worse garbage collector latency? (... when heap compaction is
> disabled?)
> And of course, for many programs such latency matters a lot less than
> thoughput...
In fact, an allocated block is visited at most twice by a minor GC and
if promoted (that if visited twice by the minor GC) at least once by the
major GC (when freed because
major GC is mark and sweep) ... So a heap allocated block is traversed
0, 1, 3 or more time by one of the GC ...

So increasing the minor heap size strictly decreases the number of time
a word is examined by one of the GC ...

I think that having two heaps is mainly (only ?) for one reason:
collecting some memory sooner (and therefore using less memory for dead
objects).
This may speed up the program because saving memory decreases cache
misses, but normaly it slows down the
program. But it is still better than one generation GCed more frequently ...

The latency is not directly related to minor collection ... If there was
only the major heap,
OCaml could still to a bit of major-gc cycle at each collection ... This
is a (good) design choice of OCaml
to have a small minor heap that can be collected in a short time by a
simple and fast "stop and copy"
algorithm.

The main problem of the bin-tree benchmark is when you know that an
object will live long enough to be promoted, you can not ask OCaml to
allocate it in the major heap directly. This is why increasing the minor
heap to have all object collected at the first GC works.

A syntax like Node#(x,d,y) to allocate a variant in the major heap
directly together with similar syntax for
tuples, records, ... could be quite useful in OCaml in general for known
long living objects ... An the is the Ancient modules for object that
will live even longer.

Cheers,
Christophe





>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs