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 D4658BC37; Tue, 29 Dec 2009 17:38:43 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAPu+OUvU4367kWdsb2JhbACBSZoGAQEBAQkLCgcTA7pAAoQxBA X-IronPort-AV: E=Sophos;i="4.47,469,1257116400"; d="scan'208";a="52935684" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Dec 2009 17:38:43 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-210-173.pools.arcor-ip.net [94.219.210.173]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MDCvo-1NBK9u3jZc-00GXmN; Tue, 29 Dec 2009 17:38:43 +0100 Received: from [192.168.1.105] (82-217-198-247.cable.quicknet.nl [82.217.198.247]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 901EEC0E8E; Tue, 29 Dec 2009 17:38:42 +0100 (CET) Subject: Re: [Caml-list] Re: multicore wish From: Gerd Stolpmann To: Xavier Leroy Cc: caml-list@yquem.inria.fr In-Reply-To: <4B38F34D.3020503@inria.fr> References: <4B2D2BC1.6020204@msu.edu> <200912221912.51017.jon@ffconsultancy.com> <87r5qk5x1j.fsf@frosties.localdomain> <200912241706.51917.jon@ffconsultancy.com> <87bphkk2ke.fsf@frosties.localdomain> <1262003315.32602.6.camel@flake.lan.gerd-stolpmann.de> <4B38F34D.3020503@inria.fr> Content-Type: text/plain Date: Tue, 29 Dec 2009 17:44:31 +0100 Message-Id: <1262105071.15527.28.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/SLwG1p8r0hj6ad3vCDCG9ykdAdUM/5Awd9CT NEWVeEXxrTJMZhouAAE0etSofZd7DBpeJkIy3hpXBtYDrFo+ww 1hVsZgaezOOuajVyOfo5A== X-Spam: no; 0.00; gerd:01 stolpmann:01 gerd:01 stolpmann:01 mli:01 hash:01 hash:01 ocaml:01 run-time:01 well-formed:01 pointer:01 pointers:01 finalisers:01 ocaml:01 runtime:01 Am Montag, den 28.12.2009, 19:05 +0100 schrieb Xavier Leroy: > Gerd Stolpmann wrote: > > > It works with all types: > > > > https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netsys/netsys_mem.mli > > > > look for init_value. It's non-released code yet. > > > > However, there are some problems: Values outside the heap do not support > > the polymorphic comparison and hash functions. That's a hard limitation, > > e.g. you cannot even compare two strings, or build a hash table with > > strings as keys. That limits the usefulness of shared memory. > > In OCaml 3.11 and later, you can call > > caml_page_table_add(In_static_area, start, end) > > to inform the run-time system that the address range [start, end) > contains well-formed Caml data that polymorphic primitives can safely > work on. This should solve your problem. Yes, in deed! Very nice. As there are still unused bits in the page table... I'm thinking about the following. One bit could be used by the GC to indicate that values somewhere in the page are still referenced from heap memory. At the beginning of the mark phase the bit is cleared. Whenever a pointer is seen that goes to a page marked as In_static_area, the bit for the area is set. As before, the mark phase ignores these pointers otherwise (they are not followed). After the mark phase, one could check which of the pages are still used, and this would make it possible to call finalisers for whole pages. As we only add an "else case" to the mark loop, the costs for this are negligible. In the shared memory scenario, each process mapping share memory could define such a finaliser, and only when it is called the memory block is unmapped. (And when a global counter is decreased to 0, the shared memory object as such can be deleted. But that's outside the ocaml runtime.) With that help, shared memory would be relatively safe to use. The only remaining trap would be value pointers that go from shared memory to heap memory - but ocaml has already lots of ways to control mutability of values, so I think it is ok to let the programmer do this. Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------