From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
From: Bakul Shah <bakul+plan9@bitblocks.com>
Date: Mon,  7 Jul 2008 11:15:50 -0700
Message-Id: <20080707181551.0531A5B4D@mail.bitblocks.com>
Subject: [9fans] lisp
Topicbox-Message-UUID: dd006630-ead3-11e9-9d60-3106f5b1d025

[Questions in the third para below.]
CMUCL "initializes" its state essentialy by loading a
previously dumped core image file.  This is slow the first
time around but once the ~25MB core image is cached,
execution is really fast and you have access to a lot of
goodies.  So a script like

#!/usr/local/bin/cmucl -script
(format t "Hello, World!~%")

can execute in a few milliseconds.  On systems with mmap(2)
or equivalent, the core image is simply copy-on-write mmaped.
This is a win since only the required pages will be loaded
(and not all of 25MB) and COW allows local changes.

>>From what I understand, to do something equivalent on plan9
would require creating a segment and copying the core file to
it.  Is this correct?  Presumably the reads are cached?  Even
so, there will the cost of copying to the segment.  Or can
one create multiple text and data segments in some way so
that stuff will be paged in as necessary?  Also, if a shared
segment is created won't the forked processes be able to
modify this segment?  Ideally one would like a private copy
for each child.  Is segattach + read the best (only?) way to
do this?

sbcl too uses a core file like cmucl.  They both compile code
so are generally faster than clisp, which is the third
alternative.  Note: my interest is purely hypothetical at the
moment.

Thanks!