From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id C3C107EE4B for ; Mon, 30 Sep 2013 15:21:59 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of lpw25@cam.ac.uk) identity=pra; client-ip=131.111.8.152; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="lpw25@cam.ac.uk"; x-sender="lpw25@cam.ac.uk"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of lpw25@cam.ac.uk) identity=mailfrom; client-ip=131.111.8.152; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="lpw25@cam.ac.uk"; x-sender="lpw25@cam.ac.uk"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@ppsw-52.csi.cam.ac.uk) identity=helo; client-ip=131.111.8.152; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="lpw25@cam.ac.uk"; x-sender="postmaster@ppsw-52.csi.cam.ac.uk"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQBABJ6SVKDbwiYnGdsb2JhbABaDoMxwU+BKxYOAQEBAQEGDQkJFCiCJQEBBAE6OgUFCwsOEyUPAQQ1ARMTiAAGBAi0LokTFo87B4QiA5kuky9A X-IPAS-Result: AmQBABJ6SVKDbwiYnGdsb2JhbABaDoMxwU+BKxYOAQEBAQEGDQkJFCiCJQEBBAE6OgUFCwsOEyUPAQQ1ARMTiAAGBAi0LokTFo87B4QiA5kuky9A X-IronPort-AV: E=Sophos;i="4.90,1007,1371074400"; d="scan'208";a="28560771" Received: from ppsw-52.csi.cam.ac.uk ([131.111.8.152]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Sep 2013 15:21:59 +0200 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 88-105-45-234.dynamic.dsl.as9105.com ([88.105.45.234]:60606 helo=netbook) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:lpw25) (TLSv1.2:DHE-RSA-AES128-SHA:128) id 1VQdQD-0000A5-FG (Exim 4.80_167-5a66dd3) (return-path ); Mon, 30 Sep 2013 14:21:57 +0100 From: Leo White To: Sungwoo Park Cc: caml-list@inria.fr References: X-Face: "XWxb[u_Z\PA_Y?9@|IA!!+jTb(/290-*ea/Un$I0B98.$n%eL.;2w*,z]WR#T:,p[ NBd++M7l]#7zj7!{~iw $W-"/=|dVjhT[D{4~gE}gK<2`.6fs!;uqqud]vs2N/3^m7{aS1V, Date: Mon, 30 Sep 2013 14:24:42 +0100 In-Reply-To: (Sungwoo Park's message of "Mon, 30 Sep 2013 21:43:20 +0900 (KST)") Message-ID: <86bo3ao31h.fsf@cam.ac.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Caml-list] Two questions on the OCAML runtime system and compiler, 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 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