Lieven, thanks for your comments.
Lieven Marchand <mal@bewoner.dma.be> writes:
> Date: 02 Jul 1999 19:25:55 +0200
> ...
[I wrote in response to a question about FASL in poplog, from Greg
Funaro <Gregory.Funaro@hsv.boeing.com>]:
> >
> > I have a hunch (I don't know why?) that it refers to an external
> > machine-code file produced by the compiler: I understand that in
> > some lisp systems the compiler works by producing such a file, which
> > can then be linked into the running lisp system. (A corrollary is
> > presumably that compiled functions cannot be automatically garbage
> > collected?)
> > ...
[LM]
> Sort of. FASL stands for fastload. It is indeed used in order to avoid
> having to recompile from source when you want to load a subsystem. On
> my system for example the fasl for clx (X client library) is 1598110 bytes
> and compiling it from source takes considerable time. On the other hand it
> is not needed for every program. So bundling it in would be a waste and
> making different versions of the lisp system with different stuff compiled
> in would give rise to a combinatorial explosion of different lisp executables.
In poplog this is provided through an "incremental" save/restore
mechanism. However it doesn't work in all contexts because it cannot be
guaranteed to restore the environment properly.
So users typically create their own saved images "layered" on top of the
system images. If you create saved image W you can create new saved
images X and Y on top of it, and Z on top of X. Then you have the choice
of running:
the original system image: pop11
pop11 +X
pop11 +X +Z
pop11 +Y
But you can't combine X and Y if they were separately saved. So this is
not as flexible as the system you describe. However, if you know the
most likely combinations required at your site you can create layered
saved images for them. This works adequately, in my experience.
E.g. we have a number of pre-compiled demonstration programs as saved
images, in addition to pop11, prolog, common lisp, and standard ml.
The sources which add common lisp to pop11 compile in about 10 seconds
on a 300 Mhz Ultrasparc 2. The saved image takes up about 2Mbytes and
starts up instantly (file-server permitting!)
> Although it isn't in the standard, (almost) every lisp implementation has a
> auto-load feature: you can compile subsystems to fasls and have these
> autoloaded in the running lisp system when a function that is defined in the
> fasl gets called.
The pop-11 autoload system works for source files, most of which compile
very fast. However some of them can link in externally compiled
procedures. As an indication of speed, the poprulebase library in
ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/prb/lib/poprulebase.p
compiles in under a second on the ultra 2, which feels almost
instantaneous to users.
> I don't get your remark about gc-ing compiled functions.
One of my colleagues Brian Logan asked me about this, and I realised
that what I had written was not clear.
The corollary I had in mind depended not on compilation alone but on
*external* compilation.
I was thinking that if a machine code file is created outside a running
lisp system, for subsequent linking in, it would be like linking in
precompiled C code, using the operating system's dynamic linker, and the
linked in code which would not have information available that the
garbage collector could use.
But on reflection I guess that's wrong: lisp could use its own linking
mechanism and the result could be the same as if the compiled procedures
had been directly added to the heap by an incremental compiler, as in
poplog.
I have heard that in some lisp systems neither compiled functions nor
arrays are garbage collected because the garbage collector works only on
lists (or lists and records?). But I don't know whether that is or ever
was true.
> How can the system
> ever decide to remove defined functions on it own?
In poplog this happens all the time if you are using the incremental
compiler and doing development work in which you create a function
perhaps initially with extra trace printing, then compile it, then
run various tests, then remove or modify the trace printing, or
fix bugs, extend functionality, etc.
Once a new version of an previously compiled function has been compiled,
if you have not declared its identifier as a constant (e.g. in pop11
"define constant foo(x,y)"), then everything which previously
accessed the old version will now access the new one (as long as you
have not stored the old one in any arrays or other data-structures).
As a result when the next garbage collection occurs the old one will
be garbage collected and the space will become available for re-use.
[LM]
> If in CL you do stuff
> like (fmakunbound 'foo) or (drop-package "MY-PACKAGE") the function foo or
> all the functions in MY-PACKAGE will indeed be gargage collected.
Poplog common lisp has fmakunbound and delete-package, but I can't
find (using grep in the lisp source directory) anything called
"drop-package". I can't find it in the index to CLTL2 either!
I expect it's a different name for the same thing.
You can do this sort of thing in Pop-11 too, though Pop-11 has
tree-structured sections not packages.
It can sometimes be very useful to get rid of functions created
temporarily e.g. functions needed only while setting up a complex
application. This will remove the words foo, baz and grum from the
dictionary;
cancel foo, baz, grum;
Then if foo is the only thing that calls procedures baz and grum and
nothing calls foo because it was invoked at top level in some
startup file, then all three functions will become inacessible
(unless explicitly stored somewhere). The garbage collector will
reclaim their space when it next runs. The section_cancel command can
get rid of everything in a section.
In poplog, unlike some (older?) lisp systems the very same heap is
used for all poplog structures: lists, records, functions, arrays,
properties, etc. However, the heap is allowed to have "holes" which
contain non-relocatable objects such as externally linked procedures
(e.g. from C or Fortran) or non-relocatable poplog objects which are
pointed to by externally compiled procedures whose pointers the
garbage collector cannot update.
> Ob-Pop: how are the negotiations for a public version of POPLOG going?
Negotiations are over: Sussex and ISL have achieved a friendly
separation as regards Poplog. It's now a question of people at Sussex
finding time to make everything happen, including tracking down and
removing references to ISL from the documentation and sources. I don't
know how long that will take: everyone in UK universities is overworked.
Meanwhile Steve Leach is setting up his new poplog site:
www.poplog.org
Unfortunately, the pop-11 testdrive account has recently acquired a
password:
if you try
telnet testdrive.popforum.org.uk
and log in as testdrive, you'll be asked for a password. You'll also
see the name of the administrator whom you can email to ask for the
password!
(I think this will change at some time, when the "testdrive" system
has been moved off the machine at HP labs to the machine at
www.poplog.org)
Aaron
===
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (NB: Anti Spam address)
PAPERS: ftp://ftp.cs.bham.ac.uk/pub/groups/cog_affect/0-INDEX.html
|