Re: [Caml-list] Two questions on the OCAML runtime system and compiler,

[Leo White <lpw25@cam.ac.uk>]

We are also experimenting with a parallel OCaml runtime system at
OCamlLabs (https://github.com/ocamllabs/ocaml/tree/multicore). Out of
interest is the source for your experimental compiler and runtime available
anywhere?

With respect to the page table, I don't think it serves any other
purpose. I know various people have been looking into removing
it (or at least removing it from common operations) without the addition
of a bit field in the header. So it is possible you could avoid changing
the header layout in your version of the compiler as well.

Regards,

Leo White

Sungwoo Park <gla@postech.ac.kr> writes:

> Dear Caml users,
>
> We are currently experimenting with a parallel Ocaml runtime system, in which
> each thread maintains its own old and young heaps and runs in parallel with
> other threads, without sharing a global lock as in the current Ocaml runtime
> system while sharing the whole memory space. We have made changes to the
> current Ocaml compiler (4.00.1), and now the parallel compiler generates
> parallel code that runs on the parallel Ocaml runtime system. It is a
> cross-compiler and we can build it with any version of the Ocaml compiler,
> including the parallel compiler itself.
>
> This is a project very similar to Luca Saiu's reentrant multi-runtime system
> (https://github.com/lucasaiu/ocaml), and we benefited very much from Luca's
> code at several early stages in the development. Similarly to Luca's work, our
> runtime system is reentrant.
>
> As the next step toward a parallel runtime system with a shared heap, we are
> struggling to redefine the tag format. I have two specific questions on the
> compiler and the runtime system. Any comment and help would be greatly
> appreciated.
>
> Question 1.
>
> When we reassign tag numbers for block types, the runtime system crashes for
> some applications. We thought we made all necessary changes to the source code
> (in byterun/mlvalues.h, utils/config.mlp, and several files in bytecomp/) to
> reflect the new tag numbers. However the runtime system often crashes, for
> example, when it accesses the Lazy module, which in turn accesses the Obj
> module, in testsuite/tests/misc/hamming.ml. I wonder what other parts in the
> source code we should revise after reassigning tag numbers.
>
> (Our finding is that this is not a problem due to the parallel runtime system,
> as we could reproduce the same outcome on the sequential runtime system.)
>
> Question 2.
>
> On a 64-bit system, can we safely get rid of the page table, in particular
> caml_page_table_lookup(), if the header of each block is redesigned to include
> a field indicating which memory area it resides (old heap, young heap, static
> data, etc)? I wonder what other purposes the page table serves, other than
> determining the memory area for a given pointer.
>
> (Perhaps adding a new field in the header would be too impractical on a 32-bit
> system, but on a 64-bit system, we can affort to allocate quite a few bits for
> new fields in the header. Windows might need the page table to check if a given
> pointer points to code, but luckily we don't need to consider Windows for our
> purpose.)
>
> Thank you very much!
>
> --- Sungwoo Park