From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 7832DBC58 for ; Mon, 13 Sep 2010 08:29:39 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloBABJhjUzRVda2kGdsb2JhbACTRTGFR4gACBUBAQEBCQkMBxEDH6RfiTKCE4VhLYglAQEDBYU7BIREhWM X-IronPort-AV: E=Sophos;i="4.56,358,1280700000"; d="scan'208";a="67461983" Received: from mail-iw0-f182.google.com ([209.85.214.182]) by mail1-smtp-roc.national.inria.fr with ESMTP; 13 Sep 2010 08:29:38 +0200 Received: by iwn34 with SMTP id 34so6641187iwn.27 for ; Sun, 12 Sep 2010 23:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=77S3cPcMByTE1Crf4GxrSgAZwYGXkd+intJFhiNgAcA=; b=F/Jh2hdagyZafbFHILO8d/6JZawmsTYTRmzMWIA/C1mm3tXSkmDN3FMM3k4J/STupb W5JM/GfF0pru9JMqpz250Y/UelKEeVOpnZEE4pY6gOYbojvXAYX2CaeHg/kNL8RxD6DV yFaFsFKxCGtBtAaCDqIrFrc7jiTAh6ApVhFqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KdWnmdIctVbUTaprUxQdAh6BcYsHjaAbFKXI7t75fPvhGue4kDwmHRd0fyvjIx+qSK 2DBXWy+2ignVHLJ01zlZxTNJRaGQwYJKcr9CmSLelXd8997XaGVqVqCBvzmR3bUGBqxx 9dyWIV+J2nqU23773y2NJx8PoZUvjumABYIvQ= MIME-Version: 1.0 Received: by 10.231.152.143 with SMTP id g15mr5672731ibw.76.1284359378193; Sun, 12 Sep 2010 23:29:38 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Sun, 12 Sep 2010 23:29:38 -0700 (PDT) Date: Mon, 13 Sep 2010 09:29:38 +0300 Message-ID: Subject: How to re-implement the GC? From: Eray Ozkural To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001636d34573804e5604901e38ab X-Spam: no; 0.00; re-implement:01 eray:01 ozkural:01 pitfalls:01 eray:01 ozkural:01 bilkent:01 pitfalls:01 bilkent:01 groups:02 groups:02 sci:04 sci:04 group:07 group:07 --001636d34573804e5604901e38ab Content-Type: text/plain; charset=ISO-8859-1 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? 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 --001636d34573804e5604901e38ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi there,

What exactly are the requirements for substitu= ting the current GC with another, preferably non-locking, GC? Any pitfalls = I wouldn't see just reading the code?

Best,
--
Eray Ozkural, PhD candidate.=A0 Comp. Sci. Dept., Bilkent Univer= sity, Ankara
htt= p://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

--001636d34573804e5604901e38ab-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 4EB62BC58 for ; Mon, 13 Sep 2010 09:57:36 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEDAGZ2jUxQW+UMgWdsb2JhbACTdo1PFQEBFiIivjmFQASIfoEphVxo X-IronPort-AV: E=Sophos;i="4.56,358,1280700000"; d="scan'208";a="57150842" Received: from lo.gmane.org ([80.91.229.12]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Sep 2010 09:57:35 +0200 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ov3uw-00069O-EJ for caml-list@inria.fr; Mon, 13 Sep 2010 09:57:34 +0200 Received: from ks368928.kimsufi.com ([94.23.39.26]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Sep 2010 09:57:34 +0200 Received: from sylvain by ks368928.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Sep 2010 09:57:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: How to re-implement the GC? Date: Mon, 13 Sep 2010 07:57:26 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ks368928.kimsufi.com User-Agent: slrn/pre1.0.0-11 (Linux) X-Spam: no; 0.00; le-gall:01 re-implement:01 eray:01 ozkural:01 pitfalls:01 compiler:01 ocaml:01 wrote:01 linear:02 bugs:03 thread:06 probably:07 quite:08 meeting:08 interesting:12 Hi, On 13-09-2010, Eray Ozkural 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. I would recommend you trying OC4MC, which is probably what you are looking for: http://www.algo-prog.info/ocmc/web/ They show quite interesting results using Thread at the last OCaml Meeting, though they are still some bugs (almost linear speed-up with multicore). Regards, Sylvain Le Gall From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 6C9ADBC58 for ; Mon, 13 Sep 2010 14:02:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcCACmvjUzRVda2kGdsb2JhbACTRYV4AYgACBUBAQEBCQkMBxEDH6R3iTKCE4VrLYglAQEDBYU7BIREhWOFXGg X-IronPort-AV: E=Sophos;i="4.56,358,1280700000"; d="scan'208";a="59177853" Received: from mail-iw0-f182.google.com ([209.85.214.182]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Sep 2010 14:02:34 +0200 Received: by iwn34 with SMTP id 34so6982038iwn.27 for ; Mon, 13 Sep 2010 05:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=TKgc1lyaODlKIarpC5atnp2ErOERqTRgN2cDdv/SUZ8=; b=bRpqNZwPVnV3br+rWCmmLE7VtIbVLon5vC5kSALY8TCPJ6fAAN7jEg7LJC7d2P8dmi vykhIZthkYhBbITNcqlwoyEHkf8gDLJlHx3cmNsKV4EjmTQMF99KaS/x0Ytu/La356DO TjHwuU2rbzVCmkCF8+RT/kE0R5ghk5iEvcg3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sYpONbdpl0C8BBiHNio/rToD1GqPUHE680Fx9bxcGvrkQw56mBp/lKGYLlwG+WAHP7 qcJpzhmoIVYeO9d70PZ4wA6nrQAXae1VHD8M/aPVIScs1LXsnaM7cCrgVG1NUK0QdNyG mN/PfLKE4acWXd0N/tbI9ie/wlr+apsSEG0d8= MIME-Version: 1.0 Received: by 10.231.15.138 with SMTP id k10mr5894431iba.17.1284379353129; Mon, 13 Sep 2010 05:02:33 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Mon, 13 Sep 2010 05:02:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Sep 2010 15:02:33 +0300 Message-ID: Subject: Re: [Caml-list] Re: How to re-implement the GC? From: Eray Ozkural To: Sylvain Le Gall Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=00221532cb5019a2a3049022df7c X-Spam: no; 0.00; re-implement:01 eray:01 ozkural:01 le-gall:01 eray:01 ozkural:01 pitfalls:01 compiler:01 compiler:01 ocaml:01 bilkent:01 le-gall:01 pitfalls:01 ocaml:01 bilkent:01 --00221532cb5019a2a3049022df7c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 13, 2010 at 10:57 AM, Sylvain Le Gall wrote: > Hi, > > On 13-09-2010, Eray Ozkural 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 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. > 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? 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 --00221532cb5019a2a3049022df7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2010 at 10:57 AM, Sylvain Le Gall <sylvain@le-gall.net> wrot= e:
Hi,

On 13-09-2010, Eray Ozkural <exa= machine@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 j= ust
> reading the code?
>

The GC is deeply interacting with the the rest of the compiler. I thi= nk
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?
=A0
I would recommend you trying OC4MC, which is probably what you are
looking for:
http://ww= w.algo-prog.info/ocmc/web/


Yes, I've seen it but it's a w= ork in progress, and it's being rewritten from scratch.
=A0
They show quite interesting results using Thread at the last OCaml
Meeting, though they are still some bugs (almost linear speed-up with
multicore).
=A0
=A0
What exactly is the GC be= ing 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?

Best,
=A0
--
Eray Ozkural, PhD= candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/a= i-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--00221532cb5019a2a3049022df7c-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id BE313BC58 for ; Mon, 13 Sep 2010 14:23:12 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMEAL60jUxQW+UMgWdsb2JhbACTdo1QFQEBFiIivmmFQASIfoEphVxo X-IronPort-AV: E=Sophos;i="4.56,359,1280700000"; d="scan'208";a="59179791" Received: from lo.gmane.org ([80.91.229.12]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Sep 2010 14:23:05 +0200 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ov83t-00080A-09 for caml-list@inria.fr; Mon, 13 Sep 2010 14:23:05 +0200 Received: from ks368928.kimsufi.com ([94.23.39.26]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Sep 2010 14:23:04 +0200 Received: from sylvain by ks368928.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Sep 2010 14:23:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: How to re-implement the GC? Date: Mon, 13 Sep 2010 12:22:56 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ks368928.kimsufi.com User-Agent: slrn/pre1.0.0-11 (Linux) X-Spam: no; 0.00; le-gall:01 re-implement:01 eray:01 ozkural:01 eray:01 ozkural:01 pitfalls:01 compiler:01 compiler:01 modular:01 afaik:01 pointer:01 ocaml:01 runtime:01 ocaml:01 On 13-09-2010, Eray Ozkural wrote: >> On 13-09-2010, Eray Ozkural 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). AFAIK, it uses some machine register to store a pointer to the minor heap. But I am not a GC expert. > >> 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. To be honest, I think that if you join your efforts with theirs, you'll probably get something quicker than going alone on this path. But this is only my opinion. At least, you will need the "fully-reentrant" runtime they are doing. >> 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. Regards, Sylvain Le Gall From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 3DC57BC58 for ; Mon, 13 Sep 2010 16:14:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoCAEvOjUzRVdI2kGdsb2JhbACTRYV4AYc7RQgVAQEBAQkJDAcRAx+nOYkyghOGBi2HcgEBAwWFOwSERIVjhVxo X-IronPort-AV: E=Sophos;i="4.56,359,1280700000"; d="scan'208";a="57183015" Received: from mail-pz0-f54.google.com ([209.85.210.54]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Sep 2010 16:14:48 +0200 Received: by pzk7 with SMTP id 7so2450297pzk.27 for ; Mon, 13 Sep 2010 07:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XO0hCUO7pmtwZklGUA4H9rlQ5WpSZ6Hmg1m39zCi6ks=; b=kazBbdirOMgF72PcZzj7+dUyHHbYxtq/wLPVNIVUt0EVfbrYI70Rhm/S8TafQ/Pn9Y 0CmkPfBVyrOKMb5vz0Ed1JJ0Cs6lhKlBAqVUXx4kpIizbqI6vRm6j1llluBpeBKWQV/R us84Yl5qt7d+Q7GNszk2lCHWSJWubrLk6XHg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oVSp/vvt6du8bbHIhWLi2LomqmemMzjcaDYUmlgnTq0B5UcHtwmTtU0cDbtXdoGsA0 rzgl1BQpUZjgPjHsG14fkRVFLg2v3MZYF9NTlLt6Takh36t7qHQFuhlYxnce/4wHRIzX V7B+eK1Iur6sdedp9Pt8307JeSwlPNUPLSd4c= MIME-Version: 1.0 Received: by 10.142.185.5 with SMTP id i5mr2993445wff.225.1284387286868; Mon, 13 Sep 2010 07:14:46 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Mon, 13 Sep 2010 07:14:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Sep 2010 17:14:46 +0300 Message-ID: Subject: Re: [Caml-list] Re: How to re-implement the GC? From: Eray Ozkural To: Sylvain Le Gall Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=000e0cd18672fce48b049024b79e X-Spam: no; 0.00; re-implement:01 eray:01 ozkural:01 le-gall:01 eray:01 ozkural:01 pitfalls:01 compiler:01 compiler:01 modular:01 afaik:01 pointer:01 speedup:01 pointer:01 ocaml:01 --000e0cd18672fce48b049024b79e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 13, 2010 at 3:22 PM, Sylvain Le Gall wrote: > On 13-09-2010, Eray Ozkural wrote: > >> On 13-09-2010, Eray Ozkural 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. > > > > >> 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? > To be honest, I think that if you join your efforts with theirs, you'll > probably get something quicker than going alone on this path. But this > is only my opinion. > Yes, if I decide to carry on I would try to join efforts. But I really need to find out what's necessary first. Hence, all the pondering. > > At least, you will need the "fully-reentrant" runtime they are doing. > > Yes, fully-entrant is necessary for any proper POSIX threads code. If the runtime had some global state, you simply carry that to local state (plugging into function args etc.) and you're done. Depends on how much global state there is. In well-designed programs, there isn't much of a global state, it's unfortunate they didn't notice the runtime wasn't reentrant at first. They would also need to pay attention to such things as volatile memory and synchronization. It can actually get quite difficult to write POSIX threads code that won't deadlock or do unexpected things, while in theory it is quite easy to write. It would be nice to have a complete checklist of everything you need to do to make sure the multithreaded code is correct, which I believe I never had so I prefer message passing :) > >> 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. 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 --000e0cd18672fce48b049024b79e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 curren= t GC with
>> > another, preferably non-locking, GC? Any pitfalls I wouldn= 9;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 inte= rface
> 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 ver= y efficient,
but not "modular or object-oriented". I would say that it is clea= n with
regard of the efficiency. But I won't use it to demonstrate how GC work= s
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 mes= sy, I suppose.
=A0
AFAIK, it uses some machine register to store a pointer to the minor
heap. But I am not a GC expert.

Ah, tha= t's interesting. I wonder if it provides any real speedup on new archit= ectures compared to storing the pointer in RAM.

>
>> 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 be= ing rewritten from
> scratch.
>
>

If you stick to 3.11.1 OCaml version, you'll be able to compile w= ith one
of their latest "stable" patch.

=A0

Which one is it?
=A0
To be honest, I think that if you join your efforts with theirs, you'll=
probably get something quicker than going alone on this path. But this
is only my opinion.

Yes, if I decide to= carry on I would try to join efforts. But I really need to find out what&#= 39;s necessary first. Hence, all the pondering.
=A0

At least, you will need the "fully-reentrant" runtime they are do= ing.


Yes, fully-ent= rant is necessary for any proper POSIX threads code. If the runtime had som= e global state, you simply carry that to local state (plugging into functio= n args etc.) and you're done. Depends on how much global state there is= . In well-designed programs, there isn't much of a global state, it'= ;s unfortunate they didn't notice the runtime wasn't reentrant at f= irst. They would also need to pay attention to such things as volatile memo= ry and synchronization. It can actually get quite difficult to write POSIX = threads code that won't deadlock or do unexpected things, while in theo= ry it is quite easy to write. It would be nice to have a complete checklist= of everything you need to do to make sure the multithreaded code is correc= t, which I believe I never had so I prefer message passing :)
=A0
>> They show quite interesting results using Thread at the last OCaml=
>> Meeting, though they are still some bugs (almost linear speed-up w= ith
>> 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 pr= ovided
> the basic changes to substitute the GC?
>

I think you won't be able to plugin your own GC. The one they pro= vide is
a "stop the world"... I am not sure though, ask them directly.
=A0

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 thi= s project actually made progress in other parts of the code (like making th= e runtime fully re-entrant) how do I go about implementing a state-of-the-a= rt GC for this, are there any special requirements or do I just have to imp= lement a minor heap and a major heap etc. to match the interface and the pa= rameters 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 compilat= ion system can do it.

Best,
=A0
--
Eray Ozkural, PhD= candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/a= i-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--000e0cd18672fce48b049024b79e-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id CCB41BC58 for ; Mon, 13 Sep 2010 16:30:04 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUEAM/RjUxQW+UMgWdsb2JhbAChRhUBARYiIsFmhUAEiH6BKYVcaA X-IronPort-AV: E=Sophos;i="4.56,359,1280700000"; d="scan'208";a="57184017" Received: from lo.gmane.org ([80.91.229.12]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Sep 2010 16:30:04 +0200 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OvA2e-0001nV-Hn for caml-list@inria.fr; Mon, 13 Sep 2010 16:29:56 +0200 Received: from ks368928.kimsufi.com ([94.23.39.26]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Sep 2010 16:29:56 +0200 Received: from sylvain by ks368928.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Sep 2010 16:29:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: How to re-implement the GC? Date: Mon, 13 Sep 2010 14:29:47 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ks368928.kimsufi.com User-Agent: slrn/pre1.0.0-11 (Linux) X-Spam: no; 0.00; le-gall:01 re-implement:01 eray:01 ozkural:01 le-gall:01 eray:01 ozkural:01 pitfalls:01 compiler:01 compiler:01 modular:01 afaik:01 pointer:01 speedup:01 pointer:01 On 13-09-2010, Eray Ozkural 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 wrote: > >> On 13-09-2010, Eray Ozkural wrote: >> >> On 13-09-2010, Eray Ozkural 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. > 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. >> >> > >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id E73C1BC58 for ; Mon, 13 Sep 2010 23:26:09 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBAAI0jkxKfVI0kGdsb2JhbACVKowkCBUBAQEBCQkMBxEDH6s/i0UBBY8iAQSFQA X-IronPort-AV: E=Sophos;i="4.56,361,1280700000"; d="scan'208";a="69454888" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Sep 2010 23:26:09 +0200 Received: by wwb17 with SMTP id 17so6277510wwb.9 for ; Mon, 13 Sep 2010 14:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=/Ksw/UF23aBA9kDNUioslR+drBDPUMoN6WHCyP008Js=; b=BFnMkRa5U35cOPSfq93gJZcKn65jrCrv0UPtofQTKC5a1C7O6szO7iJKZMK4WqFSCC zt1wu57y1UKtRm+4ltAhL1fz2v1OxqEOVTT68FPIsuf+S6CJ78bibeyINHJDA6VAFYSU MduI3Gg2bgXEGfZQRzlazHQnacpajZ5o7X34Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; b=TKaXxt4NOZAWip8pmtiTvQJY4iGW0khN+/IuGZrXNreAgvPrHvnY0S4lsV4DxDJyO6 Y1X0Qu5KdUxoMFHIvLEL8IdfAQLYUCP7/ZHTQSuoVatL+ClnKcTNDEEOzCKGSfwEMbl5 Gs3WmweoAGPfnfqSv/xafX+9X4lTCUShgq4Bs= Received: by 10.227.138.141 with SMTP id a13mr1357726wbu.208.1284413169070; Mon, 13 Sep 2010 14:26:09 -0700 (PDT) Received: from WinEight ([87.115.93.151]) by mx.google.com with ESMTPS id r18sm4259868weo.0.2010.09.13.14.26.05 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Sep 2010 14:26:07 -0700 (PDT) From: Jon Harrop To: "'Eray Ozkural'" , "'Sylvain Le Gall'" Cc: References: In-Reply-To: Subject: RE: [Caml-list] Re: How to re-implement the GC? Date: Mon, 13 Sep 2010 22:25:37 +0100 Organization: Flying Frog Consultancy Message-ID: <009601cb538a$3be05160$b3a0f420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActTTiAFKWfx+Qx8Rv2bUwcXzoUw4wANbvkw Content-Language: en-gb X-Spam: no; 0.00; re-implement:01 eray:01 ocaml:01 ocaml:01 compiler:01 recursion:01 run-time:01 ocaml's:01 bytecode:01 compilation:01 speedup:01 pointer:01 cheers:01 polymorphic:01 garbage:01 Hi Eray, Retrofitting a new multicore-friendly GC onto OCaml is difficult for two main reasons: 1. You want plug-and-play GCs but the OCaml compiler is tightly coupled to the old GC (although OC4MC has decoupled them!). 2. Recovering similar performance whilst reusing the same data representation is extremely difficult because the current design relies so heavily on lightweight allocation. You really want to change the data representation to avoid unnecessary boxing (e.g. never box or tag int, floats or tuples) in order to reduce the allocation rate and, consequently, the stress on the garbage collector but OCaml cannot express value types and its ability to represent polymorphic recursion makes this extremely difficult to implement. As Sylvain has said, OC4MC is your best bet if you want to try to write a new GC for OCaml. However, making more extensive changes has the potential to address many more problems (e.g. convey run-time type information for generic printing) so you might consider alternatives like trying to compile OCaml's bytecode into HLVM's IR for JIT compilation because HLVM already has a multicore friendly GC and it is much easier to develop. > Ah, that's interesting. I wonder if it provides any real speedup on new > architectures compared to storing the pointer in RAM. For a multicore GC, using a register to refer to thread-local data is a huge win because accessing thread-local data is very slow. I made that mistake in HLVM's first multicore-capable GC and it was basically useless as a consequence because all of the time was spent looking up thread-local data. When I started passing the thread-local data around as an extra argument to every function (not necessarily consuming a register all the time because LLVM is free to spill it), performance improved enormously. Cheers, Jon. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 29B1EBC58 for ; Mon, 13 Sep 2010 23:26:12 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBAAI0jkxKfVK2kGdsb2JhbACVKowkCBUBAQEBCQkMBxEDH6s/i0UBBY8iAQSFQA X-IronPort-AV: E=Sophos;i="4.56,361,1280700000"; d="scan'208";a="67523054" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail1-smtp-roc.national.inria.fr with ESMTP; 13 Sep 2010 23:26:11 +0200 Received: by wyb33 with SMTP id 33so8692516wyb.27 for ; Mon, 13 Sep 2010 14:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-cr-hashedpuzzle:x-cr-puzzleid; bh=W3ZxcTu3HpElozEyopcyx93xm2j1oUMdtcLruGhbrQU=; b=kx3+paSRVelsnuLFlwJyPNV67lGDyxrG5xP8TwP326U9avLXWKQNk3X4Y2y0eNqBZG mTNUtngDMBELA+OAK8X6owjcwLaa+zow9KLxZTvgPMMwggh+acApb0Sv1Wf4AR+5plzL v4HikOZi1U4JOoZoJ87FM7QP18u9IMAZcxhQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-cr-hashedpuzzle:x-cr-puzzleid; b=upqTAd23IQMVTNsask2SB8FdqUB8IUY6NXnVkQpGP47vEZSWbHo7B+CNm5+ByFRODq 6PQExzgV4L+108QWQarDrtVZDLwMEhV0uJmU67PxVRe1JKfpVHbH01Cz3u7EzVFZ3Eqo g1Q+31EqGwoXyim9tVVjP8/T7bvQXuEnQJ5U8= Received: by 10.216.12.139 with SMTP id 11mr4910642wez.63.1284413171121; Mon, 13 Sep 2010 14:26:11 -0700 (PDT) Received: from WinEight ([87.115.93.151]) by mx.google.com with ESMTPS id r18sm4259868weo.0.2010.09.13.14.26.09 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Sep 2010 14:26:10 -0700 (PDT) From: Jon Harrop To: "'Sylvain Le Gall'" , References: In-Reply-To: Subject: RE: [Caml-list] Re: How to re-implement the GC? Date: Mon, 13 Sep 2010 22:25:37 +0100 Organization: Flying Frog Consultancy Message-ID: <009701cb538a$3d91d1f0$b8b575d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActTUEMxA7R/nO76SvyglnGiTzeTfAANpnJA Content-Language: en-gb x-cr-hashedpuzzle: AWiU AZl2 CBCk DBSP D500 IE13 KqxR Kxjr PsWr QR7x RIgq SieM SpRI TWRq Tuie YSJD;2;YwBhAG0AbAAtAGwAaQBzAHQAQABpAG4AcgBpAGEALgBmAHIAOwBzAHkAbAB2AGEAaQBuAEAAbABlAC0AZwBhAGwAbAAuAG4AZQB0AA==;Sosha1_v1;7;{73AF0CA1-F682-4526-9A5F-E26C03D7C6EF};agBvAG4AQABmAGYAYwBvAG4AcwB1AGwAdABhAG4AYwB5AC4AYwBvAG0A;Mon, 13 Sep 2010 21:14:13 GMT;UgBFADoAIABbAEMAYQBtAGwALQBsAGkAcwB0AF0AIABSAGUAOgAgAEgAbwB3ACAAdABvACAAcgBlAC0AaQBtAHAAbABlAG0AZQBuAHQAIAB0AGgAZQAgAEcAQwA/AA== x-cr-puzzleid: {73AF0CA1-F682-4526-9A5F-E26C03D7C6EF} X-Spam: no; 0.00; re-implement:01 mutation:01 ocaml:01 mutation:01 ocaml:01 cheers:01 nursery:98 caml-list:01 minor:01 algorithm:01 objects:02 objects:02 assumption:08 heaps:10 jvm:11 > Other GC algorithm for Java/C# often made the assumption of long-living > objects with mutation. This is not the case for OCaml. They do favour mutation and, consequently, have cheaper write barriers but both the JVM and CLR use pointer-bumping minor heaps for the first "nursery" generation to collect short-lived objects efficiently, just like OCaml. Cheers, Jon. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 43344BC58 for ; Mon, 13 Sep 2010 23:47:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggCADs4jkzRVda2kGdsb2JhbACTWYV1AYgACBUBAQEBCQkMBxEDH6sdiTKCE4ZYLYgkAQEDBYU7BIREhWM X-IronPort-AV: E=Sophos;i="4.56,361,1280700000"; d="scan'208";a="59211517" Received: from mail-iw0-f182.google.com ([209.85.214.182]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Sep 2010 23:47:23 +0200 Received: by iwn34 with SMTP id 34so7439499iwn.27 for ; Mon, 13 Sep 2010 14:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5y0wV4OTKpP5vlsG3GmivLtCbGuFTHdUGAk+7BzmJds=; b=f9An+3fedW/PiDq2iTnNxihPEKbbtu1vuRcN1QVHHDGtTAEiWLBlorLaqvsZRMmXza kPGBgpgk/IV2hwoTriIoK9B7dPR+ctNwIgVP9uZnKAAspAoM6FGi/bBovBvpIlnO/Tiq Q3DcmOOnem94tguh+JJhv+KzyzKc3ZraX6BK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PzQIjqkgfCvEsDaW5N6HrvsJMQ7xvNoAiEd4g+OXrvsQ/iukwkzYhBhCVP0dbZLj8G 9/3FBpkUveMQ8I3nfhjI0gesHEEWHBZo5KHjFNa5itZ15oye6avqb34uTXGntNCgCs0E oafFEnjPIsjOSs8oxpU5cCgdJaX1imxzhdKAs= MIME-Version: 1.0 Received: by 10.231.12.139 with SMTP id x11mr6231990ibx.67.1284414443074; Mon, 13 Sep 2010 14:47:23 -0700 (PDT) Received: by 10.231.159.131 with HTTP; Mon, 13 Sep 2010 14:47:23 -0700 (PDT) In-Reply-To: <009601cb538a$3be05160$b3a0f420$@com> References: <009601cb538a$3be05160$b3a0f420$@com> Date: Tue, 14 Sep 2010 00:47:23 +0300 Message-ID: Subject: Re: [Caml-list] Re: How to re-implement the GC? From: Eray Ozkural To: Jon Harrop Cc: Sylvain Le Gall , caml-list@inria.fr Content-Type: multipart/alternative; boundary=0003255761d29fb5d604902b0ad3 X-Spam: no; 0.00; re-implement:01 eray:01 ozkural:01 eray:01 ocaml:01 ocaml:01 compiler:01 ocaml's:01 cheers:01 ozkural:01 bilkent:01 compiler:01 ocaml's:01 cheers:01 bilkent:01 --0003255761d29fb5d604902b0ad3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 14, 2010 at 12:25 AM, Jon Harrop < jonathandeanharrop@googlemail.com> wrote: > Hi Eray, > > Retrofitting a new multicore-friendly GC onto OCaml is difficult for two > main reasons: > > 1. You want plug-and-play GCs but the OCaml compiler is tightly coupled to > the old GC (although OC4MC has decoupled them!). > > I'm not really interested in changing anything else at the moment. I am just looking to see if I can commission the implementation of a state-of-the-art GC and plug it into ocaml. Naturally, like anyone, I have my own ideas about how to correctly optimize dynamic memory allocation but I can take ocaml's idea, that of using two heaps and go with it. So, oc4mc was successful in decoupling after all? I need to go back and take a look at the source again. It's getting complicated quickly :) Cheers, -- 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 --0003255761d29fb5d604902b0ad3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 14, 2010 at 12:25 AM, Jon Harrop <jon= athandeanharrop@googlemail.com> wrote:
Hi Eray,

Retrofitting a new multicore-friendly GC onto OCaml is difficult for two main reasons:

1. You want plug-and-play GCs but the OCaml compiler is tightly coupled to<= br> the old GC (although OC4MC has decoupled them!).

<= br>
I'm not really interested in changing anything else at th= e moment. I am just looking to see if I can commission the implementation o= f a state-of-the-art GC and plug it into ocaml. Naturally, like anyone, I h= ave my own ideas about how to correctly optimize dynamic memory allocation = but I can take ocaml's idea, that of using two heaps and go with it. So= , oc4mc was successful in decoupling after all? I need to go back and take = a look at the source again. It's getting complicated quickly :)

Cheers,

--
Eray Ozkural, PhD candida= te.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philos= ophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--0003255761d29fb5d604902b0ad3--