[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!
