gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Shared memory use of sbcl (or any other implementation)


From: Camm Maguire
Subject: [Gcl-devel] Re: Shared memory use of sbcl (or any other implementation)
Date: 26 Oct 2005 10:17:21 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Greetings!

Juliusz Chroboczek <address@hidden> writes:

> "Benjamin Dauvergne" <address@hidden>:
> 
> > 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                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]