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 D26F27EE4B for ; Mon, 30 Sep 2013 14:37:07 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gla@postech.ac.kr) identity=pra; client-ip=141.223.1.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gla@postech.ac.kr"; x-sender="gla@postech.ac.kr"; x-conformance=sidf_compatible Received-SPF: SoftFail (mail3-smtp-sop.national.inria.fr: domain of gla@postech.ac.kr is inclined to not designate 141.223.1.24 as permitted sender) identity=mailfrom; client-ip=141.223.1.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gla@postech.ac.kr"; x-sender="gla@postech.ac.kr"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mail4.postech.ac.kr designates 141.223.1.24 as permitted sender) identity=helo; client-ip=141.223.1.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gla@postech.ac.kr"; x-sender="postmaster@mail4.postech.ac.kr"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYGAE9vSVKN3wEYdGdsb2JhbABagz+tAZROgSoWDgEMFQg8gmQCOgWBKgGIMLQeiROPUR2EDAOJN493hQSOeQ X-IPAS-Result: AvYGAE9vSVKN3wEYdGdsb2JhbABagz+tAZROgSoWDgEMFQg8gmQCOgWBKgGIMLQeiROPUR2EDAOJN493hQSOeQ X-IronPort-AV: E=Sophos;i="4.90,1007,1371074400"; d="scan'208";a="28553555" Received: from mail4.postech.ac.kr ([141.223.1.24]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Sep 2013 14:37:04 +0200 Received: from [141.223.91.81] ([141.223.91.81]) by mail4.postech.ac.kr ([141.223.1.24]) with ESMTP id 1380544631.343899.29137808.mail4 for <>; Mon, 30 Sep 2013 21:37:11 +0900 (KST) Received: from pl.postech.ac.kr (localhost [127.0.0.1]) by pl.postech.ac.kr (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id r8UChM5p026876; Mon, 30 Sep 2013 21:43:22 +0900 Received: from localhost (gla@localhost) by pl.postech.ac.kr (8.14.4/8.14.4/Submit) with ESMTP id r8UChKCQ026871; Mon, 30 Sep 2013 21:43:22 +0900 X-Authentication-Warning: pl.postech.ac.kr: gla owned process doing -bs Date: Mon, 30 Sep 2013 21:43:20 +0900 (KST) From: Sungwoo Park To: caml-list@inria.fr cc: Sungwoo Park X-TERRACE-DUMMYSUBJECT: Terrace Spam system * Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-TERRACE-SPAMMARK: NO (SR:25.40) (by Terrace) X-TERRACE-SCANRST: IPR=0 MSGR=22 X-Validation-by: gla@postech.ac.kr Subject: [Caml-list] Two questions on the OCAML runtime system and compiler, 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