From: Benjamin Geer <benjamin.geer@misys.com>
To: caml-list@inria.fr
Cc: caml@inria.fr
Subject: [Caml-list] Suggestion: a possible alternative to shared libraries?
Date: Mon, 14 Jun 2004 15:23:47 +0100 [thread overview]
Message-ID: <40CDB4F3.6010203@misys.com> (raw)
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
next reply other threads:[~2004-06-14 14:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-14 14:23 Benjamin Geer [this message]
2004-06-14 15:03 ` Gerd Stolpmann
2004-06-14 15:37 ` Benjamin Geer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40CDB4F3.6010203@misys.com \
--to=benjamin.geer@misys.com \
--cc=caml-list@inria.fr \
--cc=caml@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox