caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sylvain Le Gall <sylvain@le-gall.net>
To: caml-list@inria.fr
Subject: Re: How to re-implement the GC?
Date: Mon, 13 Sep 2010 14:29:47 +0000 (UTC)	[thread overview]
Message-ID: <slrni8sdar.skq.sylvain@gallu.homelinux.org> (raw)
In-Reply-To: <AANLkTi=9d4A=aUyhQEhu6KgjQ4bhTd3by_cXbyy0Ew0U@mail.gmail.com>

On 13-09-2010, Eray Ozkural <examachine@gmail.com> wrote:
> --===============0758070018==
> Content-Type: multipart/alternative; boundary=000e0cd18672fce48b049024b79e
>
> --000e0cd18672fce48b049024b79e
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Sep 13, 2010 at 3:22 PM, Sylvain Le Gall <sylvain@le-gall.net>wrote:
>
>> On 13-09-2010, Eray Ozkural <examachine@gmail.com> wrote:
>> >> On 13-09-2010, Eray Ozkural <examachine@gmail.com> wrote:
>> >> > Hi there,
>> >> >
>> >> > What exactly are the requirements for substituting the current GC with
>> >> > another, preferably non-locking, GC? Any pitfalls I wouldn't see just
>> >> > reading the code?
>> >> >
>> >>
>> >> The GC is deeply interacting with the the rest of the compiler. I think
>> >> you will spend a lot of time on this task.
>> >>
>> >>
>> > Deeply interacting with the compiler, how? Not through the public
>> interface
>> > of GC? Do you mean it is not used in a clean way?
>> >
>>
>> I am not sure how you define "clean way". I think it is very efficient,
>> but not "modular or object-oriented". I would say that it is clean with
>> regard of the efficiency. But I won't use it to demonstrate how GC works
>> to student (but I won't either show them real world implementation of
>> other GC which are always more complex when optimization is required).
>>
>>
> Well, programming anything in C is messy, I suppose.
>
>
>> AFAIK, it uses some machine register to store a pointer to the minor
>> heap. But I am not a GC expert.
>>
>
> Ah, that's interesting. I wonder if it provides any real speedup on new
> architectures compared to storing the pointer in RAM.
>

<take this with care, I am still not a GC expert>
I think it provides an ultra quick way to allocate data on the minor
heap. For heavy allocating programming languages like FP, it is a good
speedup.

Other GC algorithm for Java/C# often made the assumption of long-living
objects with mutation. This is not the case for OCaml. 
</take this with care>

>>
>> >
>> >> I would recommend you trying OC4MC, which is probably what you are
>> >> looking for:
>> >> http://www.algo-prog.info/ocmc/web/
>> >>
>> >>
>> > Yes, I've seen it but it's a work in progress, and it's being rewritten
>> from
>> > scratch.
>> >
>> >
>>
>> If you stick to 3.11.1 OCaml version, you'll be able to compile with one
>> of their latest "stable" patch.
>>
>>
> http://www.algo-prog.info/ocmc/distribution/
>
> Which one is it?
>

Maybe this one:
http://www.algo-prog.info/ocmc/distribution/oc4mc-toronto-stack32k.tar.gz

It seems to be based on 3.11.1. I really don't know in fact, I am not a
oc4mc expert.

>
>> >> They show quite interesting results using Thread at the last OCaml
>> >> Meeting, though they are still some bugs (almost linear speed-up with
>> >> multicore).
>> >>
>> >
>> >
>> > What exactly is the GC being used there? Is it a custom algorithm or a
>> known
>> > one? Could we plug our own algorithm to the oc4mc if it has already
>> provided
>> > the basic changes to substitute the GC?
>> >
>>
>> I think you won't be able to plugin your own GC. The one they provide is
>> a "stop the world"... I am not sure though, ask them directly.
>>
>>
>
> That's unfortunate, too, because from reading their source code I had had
> the impression that they had in mind an easy way to plug-in my GC. One with
> global lock isn't good enough though, it will not have good performance with
> memory intensive programs. Hence, my question, suppose this project actually
> made progress in other parts of the code (like making the runtime fully
> re-entrant) how do I go about implementing a state-of-the-art GC for this,
> are there any special requirements or do I just have to implement a minor
> heap and a major heap etc. to match the interface and the parameters and I
> am done? I mean, is this a garbage collector as we know it, or does it have
> any exotic features or requirements? I am looking to see if a competent
> programmer without an intimate knowledge of the whole compilation system can
> do it.
>

I really don't know how to answer, contact directly the OC4MC team. I
only answer you with the data they give at OCaml Meeting, back in April. 

Regards
Sylvain Le Gall


  reply	other threads:[~2010-09-13 14:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13  6:29 Eray Ozkural
2010-09-13  7:57 ` Sylvain Le Gall
2010-09-13 12:02   ` [Caml-list] " Eray Ozkural
2010-09-13 12:22     ` Sylvain Le Gall
2010-09-13 14:14       ` [Caml-list] " Eray Ozkural
2010-09-13 14:29         ` Sylvain Le Gall [this message]
2010-09-13 21:25           ` Jon Harrop
2010-09-13 21:25         ` Jon Harrop
2010-09-13 21:47           ` Eray Ozkural

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=slrni8sdar.skq.sylvain@gallu.homelinux.org \
    --to=sylvain@le-gall.net \
    --cc=caml-list@inria.fr \
    /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).