From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA16105; Mon, 14 Jun 2004 17:03:11 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA13526 for ; Mon, 14 Jun 2004 17:03:10 +0200 (MET DST) Received: from mail.npc.de (fw.npc.de [62.225.140.214]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5EF38SH011390 for ; Mon, 14 Jun 2004 17:03:09 +0200 Received: from styx.ffm.npc.de (lion.npc.de [192.168.129.1]) by mail.npc.de (Postfix) with ESMTP id 8ABAC17AE; Mon, 14 Jun 2004 17:03:07 +0200 (CEST) Received: from hera.ffm.npc.de (hera.ffm.npc.de [192.168.130.8]) by styx.ffm.npc.de (Postfix STYX NPC GmbH) with ESMTP id F10BAC437; Mon, 14 Jun 2004 17:03:06 +0200 (CEST) Received: from ares.ffm.npc.de (ares.ffm.npc.de [192.168.130.32]) by hera.ffm.npc.de (Postfix HERA NPC GmbH) with ESMTP id B4033159C9; Mon, 14 Jun 2004 17:03:06 +0200 (CEST) Received: from ares.ffm.npc.de (ares.ffm.npc.de [192.168.130.32]) by ares.ffm.npc.de (Postfix ARES NPC GmbH) with ESMTP id 81A611855; Mon, 14 Jun 2004 17:03:06 +0200 (CEST) Subject: Re: [Caml-list] Suggestion: a possible alternative to shared libraries? From: Gerd Stolpmann To: Benjamin Geer Cc: caml-list@inria.fr In-Reply-To: <40CDB4F3.6010203@misys.com> References: <40CDB4F3.6010203@misys.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Jun 2004 17:03:06 +0200 Message-Id: <1087225386.23883.51.camel@ares> Mime-Version: 1.0 X-Miltered: at concorde with ID 40CDBE2C.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 2004:99 in-memory:01 ideally:01 read-only:01 in-memory:01 read-only:01 model:01 cmas:01 footprint:01 cmas:01 non-trivial:01 caml's:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Am Mon, 2004-06-14 um 16.23 schrieb Benjamin Geer: > The reasoning is as follows: if many small programs use the same large > library, each of the small programs will require a lot of memory. > Rather than create shared libraries to get around this, the idea is to > write the in-memory representation of libraries (ideally on an as-needed > basis) into a cache consisting of one or more files that can be mapped > read-only into memory; that memory could then be shared by multiple Caml > processes that needed to use the same libraries. Basically, a shared library _is_ an in-memory representation of the code to be mapped into memory. There is a bit of additional stuff that makes it complicated, in particular the file format is organized such that most of the file can be mapped read-only, and only a small fraction is mapped read-write (e.g. for address relocations). So you are only re-inventing the wheel, at least if you want to do it for native code. I read the announcement differently. As Java is based on bytecode, and the .class files are transformed after being loaded into memory (to increase speed, this may or may not include JIT compiling), they are dumping the memory after this transformation, and emulate a kind of shared library for their execution model. They cannot use normal shared libraries because they don't use normal ways of code representation, that's why it is reasonable to port this wheel to the Java vehicle. One can discuss whether one should do the same for O'Caml bytecode. In particular, neither bytecode executables nor loaded CMAs are loaded by memory mapping. When I am not completely wrong, executables could be loaded by mapping them read-only (at least in the case when no endianess transformation is necessary), as they are mainly a memory footprint. For CMAs, a non-trivial change of the file format would be necessary as the loader performs relocations, and these relocations should be restricted to certain memory areas to maximize memory sharing. > Perhaps Caml's existing MD5 signatures for libraries could be used to > distinguish between an older version of a library and a newer one, so > each Caml process would only memory-map the version that it was > originally linked with, in order to avoid the "DLL hell" problem that > Xavier points out. Much easier: Include the MD5 signature in the name of the shared library. However, the hell persists: You don't know which versions are still in use. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners