CMUCL developments and OS support

[Douglas Thomas Crosher]

> system.  We have been discussing various alternatives for about
> a week and have settled on using CMU-CL on top of a minimal Linux
> system, as our initial configuration.  We would like to cooperate
> with the developers of CMU-CL in order to do this.  Eventually we
> would need to modify CMU-CL in order to integrate it with the
> Linux kernel.  But first we would like to find out what plans the
> CMU-CL developered have for adding threading.  As we will need this
> in our project.

I've been working on a generationsl GC for cmucl. Some better OS
support/integration could help:

- The generational GC currently uses page write protection to maintain
dirty bits, if the OS could maintain these it may save some overhead.

- CMUCL unmaps and remaps pages to let the OS know that they can be
zero filled and don't need to be written out to disk.  The current
support for this on freebsd is dismal, and it is better to just let
the OS page out the dirty pages!  Linux may be better.

- Perhaps the VM and GC could work better together, although a total
re-think of the GC strategy may be appropriate to achieve top
performance?

- Have been think about a memory allocation strategy that would work
with multithreads while still allowing compact and fast inline
allocation. Have noted may issues but have no workable solution
yet.

- The x86 port is not currently interrupt safe. A compact inline
pseudo-atomic function needs to be implemented that can be wrapped
around small pieces of code, E.g. object initialisation, perhaps
memory allocation? It may be that the OS could help a process
implement pseudo-atomic and without-interrupts.

- Gaining access to the FP state is problematic on FreeBSD, and
apparently there are problems on linux also.

- No-one has got single-stepping to work on linux which is necessary
for tracing and breakpoints. Even the FreeBSD support is difficult,
requiring code modification; should be able to work just using the
single step trap and an x86 flag set from the interrupted state.

- Backtracing is currently unreliable on the x86, this could be
improved if a single calling convention could be used. At present the
lisp convention differs from the C convertions and on the x86 both use
the same stack.  Another big win here would be saving a reset of the
NPX state on C calls; cmucl x86 works with all the FP registers full
so it can use them a register set not as a stack, each C call requires
the FP state to be setup for C and reset for lisp.

Regards
Douglas Crosher