caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "John F. Carr" <jfc@MIT.EDU>
To: Raoul Duke <raould@gmail.com>
Cc: caml-list <caml-list@inria.fr>
Subject: [Caml-list]  meta-gc (Re: concurrent gc?)
Date: Thu, 24 Jul 2014 15:34:54 -0400	[thread overview]
Message-ID: <21457.24542.885574.750018@gargle.gargle.HOWL> (raw)
In-Reply-To: <CAJ7XQb6KZrjqj=4hdMEkWZd=KT47xmwu=E-6x7wDjam3Vz6zPQ@mail.gmail.com>


 > to kick the question up a meta-level: Does anybody have thoughts on
 > how to best orthogonalize actual memory allocation from where the
 > application says it wants it? I mean if I write a stupid loop that
 > makes a zillion particles in the middle of each frame render then yes
 > I'm an idiot, sure... but what things can be done to actually allow
 > such idiocy to squeak by?

If you know in advance when you will need to run uninterrupted by
garbage collection, set the minor heap size large before that period.

If the minor heap size is X words and a collection has just completed,
the next collection will occur when any of the following is true:

1. You have allocated X words of small objects, i.e. those that
are 256 words or less exclusive of header.  These are allocated
from the minor heap.

2. You have allocated X words of large objects, i.e. those that are
257 words or more exclusive of header.  These are allocated from the
major heap and count as "old" even though they are new.

3. You have stored too many newly created small objects into objects
that are either large or existed before the last GC, i.e. created too
many old to young references.  Set OCAMLRUNPARAM=v=8 and look for
"ref_table threshold crossed" to see how often you hit this condition.
It should be rare.

Example:

	let a = Array.create 300 0
	let b = Array.create 300 {x=0}
	let c = [|0|]
	let d = 0
	let e = 0.0

and assume all of these values are live (used later).

The first line allocates 301 words in the major heap.

The second line allocates 301 words in the major heap, 2 words
in the minor heap, and creates 300 major to minor (old to young)
references.

The third line allocates 2 words in the minor heap.

The fourth line does not allocate memory from the heap.

The fifth line may allocate 0, 2, or 3 words from the minor heap.

  reply	other threads:[~2014-07-24 19:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24 17:37 Raoul Duke
2014-07-24 19:34 ` John F. Carr [this message]
2014-07-24 19:46   ` Raoul Duke
2014-07-25  7:28 ` Nicolas Boulay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21457.24542.885574.750018@gargle.gargle.HOWL \
    --to=jfc@mit.edu \
    --cc=caml-list@inria.fr \
    --cc=raould@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).