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 QAA30214; Mon, 14 Jun 2004 16:23:54 +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 QAA30381 for ; Mon, 14 Jun 2004 16:23:53 +0200 (MET DST) Received: from rly06a.srv.mailcontrol.com (cluster-a.mailcontrol.com [80.69.8.190]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5EENpSH005605 for ; Mon, 14 Jun 2004 16:23:52 +0200 Received: from pigeon.misys.com ([217.196.235.2]) by rly06a.srv.mailcontrol.com (MailControl) with SMTP id i5EENo0o001342 for ; Mon, 14 Jun 2004 15:23:50 +0100 Received: From gull.misys.com ([10.80.48.7]) by pigeon.misys.com (WebShield SMTP v4.5 MR1a); id 1087223560750; Mon, 14 Jun 2004 15:32:40 +0100 Received: from wimex1.midas-kapiti.com (WIMEX1 [10.80.48.218]) by gull.misys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MZTTGAVD; Mon, 14 Jun 2004 15:28:38 +0100 Received: from misys.com (PIGTAIL [10.80.56.204]) by wimex1.midas-kapiti.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LJ9Y8NSY; Mon, 14 Jun 2004 15:24:08 +0100 Message-ID: <40CDB4F3.6010203@misys.com> Date: Mon, 14 Jun 2004 15:23:47 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@inria.fr CC: caml@inria.fr Subject: [Caml-list] Suggestion: a possible alternative to shared libraries? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MailControl A-04-00-00 (www.mailcontrol.com) X-Miltered: at concorde with ID 40CDB4F7.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; leroy's:01 bug:01 bug:01 in-memory:01 ideally:01 read-only:01 caml's:01 installer:01 installer:01 invocations:01 footprint:01 read-only:01 bin:01 linked:01 caml-bugs:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk The pros and cons of being able to create shared libraries in Caml have been abundantly discussed on this list. I've been thinking about the reasons why I originally thought it would be a good idea[1], and Xavier Leroy's very reasonable objections[2], and then I read about this enhancement which Sun has added to its 1.5 JVM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4416624 (I've included the most relevant bits of that page at the bottom of this email.) Reading this, it occurred to me to ask whether a similar approach might provide similar benefits for Caml. 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. 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. Could someone in the Caml development team tell me whether this is a completely crazy idea? Ben [1] http://caml.inria.fr/bin/caml-bugs/feature%20wish?id=2372;user=guest;selectid=2372 [2] http://caml.inria.fr/archives/200405/msg00295.html ************************** [Description of the Sun JVM enhancement:] When the JRE is installed on supported platforms using the Sun provided installer, the installer loads a set of classes from the system jar file into a private internal representation, and dumps that representation to a file, called a "shared archive".... During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes.... The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive, currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes. Previously this data was replicated in each JVM instance. Second, less data is loaded out of the shared archive because the metadata for unused methods remains completely untouched as opposed to being created and processed during class loading. These savings allow more applications to be run concurrently on the same machine. ------------------- 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