I read on a mailling-list about parrot (the VM of the new PERL6) that
they
intended to have a repository of pre-compiled because when
you have 200 user running perl programs you would like them to use
shared
object to not waste memory.
Are fasl files a kind of shared object in sbcl ? If not, how current
lisp implementation resolve this problem ? How would work(with respect
to read only memory use) a system with only lisp programs ?
( i know that there is too much shared libraries in use on a typical
linux system, but the solution is not to remove all :) )
"Benjamin Dauvergne" <··················@gmail.com>:
> Are fasl files a kind of shared object in sbcl ?
No. You could think of CMUCL/SBCL FASL files as a very high-level
form of binary patch.
> If not, how current lisp implementation resolve this problem ?
CMUCL and SBCL work by doing a private Copy-on-Write mapping of the
image file. LOAD patches memory with the contents of the FASL file.
CLISP works similarly, although the image file is bytecode, and hence
much more compact, and the FASL format is much more primitive.
GCL uses an image, but FASL files are binaries ready to be mmapped;
I'm not quite sure if they actually are, but I'd guess they are simply
dlopen'ed.
ECL uses a more involved scheme that is rumoured to provide good
sharing, but someone else will need to fill in the details.
In the proprietary world, I believe that both LispWorks and ACL use
the same scheme as CMUCL -- but I could be wrong about that.
> How would work(with respect to read only memory use) a system with
> only lisp programs ?
In the CMUCL case, the images would be shared, but loading any FASL
files would trigger CoW, which would cause pages to be unshared.
If users decided to use private images in order to minimise startup
times, everything would become unshared.
> i know that there is too much shared libraries in use on a typical
> linux system, but the solution is not to remove all :) )
Well, I believe that CMUCL was designed with the assumption that
single-user workstations are the norm, and mainframes are obsolete.
In such an environment, it should be possible to dump an image with
all the software that you actually use -- think of the image as being
the precompiled repository.
On a multi-user system (where users would likely want different
software in their image), you're probably in trouble. An easy to
implement solution to this problem would be support for incremental
images. (Thanks to Fare for suggesting that on CL-Debian.)
Juliusz
>ECL uses a more involved scheme that is rumoured to provide
>good sharing, but someone else will need to fill in the details.
In ECL, binary files are actually shared libraries and as thus can be
used by many different processes.
In order to avoid the limitations of many operating systems in the
number of libraries one may load, FASL files can be garbage collected
as a whole when there are no references to the functions defined in
them.
Currently there is the limit that you cannot load twice a FASL file,
because many operating systems compare shared libraries based on their
name and do not use the date (i.e. if a FASL file is updated, the
system will not reload it, but just use the copy which is already in
memory). We are working on a cleverer way to handle this.
Juanjo
On Prickle-Prickle, The Aftermath 2, 3171 YOLD, Juliusz Chroboczek wrote:
> ECL uses a more involved scheme that is rumoured to provide good
> sharing, but someone else will need to fill in the details.
ECL uses plain OS dlopen() (or, on Windows, equivalent call handling
dll files), which is OS's way of sharing dynamically loadable code
between processes. Code is shared, data is copied-on-write.
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...when I was a little kid, my mother told me not to stare
,|{-}|}| }\/ into the sun. So once, when I was six, I did. The doctors didn't
\/ |____/ know if my eyes would ever heal... } ( Darren Aronofsky, Pi ) -><-
Greetings!
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> "Benjamin Dauvergne" <··················@gmail.com>:
>
> > Are fasl files a kind of shared object in sbcl ?
>
> No. You could think of CMUCL/SBCL FASL files as a very high-level
> form of binary patch.
>
> > If not, how current lisp implementation resolve this problem ?
>
> CMUCL and SBCL work by doing a private Copy-on-Write mapping of the
> image file. LOAD patches memory with the contents of the FASL file.
>
> CLISP works similarly, although the image file is bytecode, and hence
> much more compact, and the FASL format is much more primitive.
>
> GCL uses an image, but FASL files are binaries ready to be mmapped;
> I'm not quite sure if they actually are, but I'd guess they are simply
> dlopen'ed.
>
Actually, GCL has a quite low-level native object file relocation and
loading mechanism like that used in lush for example. 'fasl' files
are genuine elf object executables, not-shared, output by gcc. On
loading, the code is relocated given the symbol table of the running
image, and the code body is managed in memory with the standard memory
subsystem, i.e. will be gc'ed when unused. The memory image
containing such code can be dumped to disk via si::save-system into a
stand-alone executable, hence gcl is doing much of the work ld would
do in the C world. This also gets around nasty system resource limits
on dlopen, notably open file descriptor limits, as well as ensuring
code location on subsequent image execution allowing faster call
mechanisms. We've extended this functionality recently to mips and
alpha architectures, leaving only ia64 and hppa among the Debian
platforms which must fall back to dlopen at present. I would also
like to extend this in the future to allow loading modules which refer
to symbols in external shared libraries, and having GCL's unexec
modify the program header of the disk image to reload said library on
re-execution. If anyone wants to help with this, please let me know.
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah