Re: [Caml-list] Re: multicore wish

[Gerd Stolpmann <gerd@gerd-stolpmann.de>]

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
------------------------------------------------------------