CMUCL developments and OS support

[Peter.VanEynde]

On Wed, 30 Apr 1997, Douglas Thomas Crosher wrote:

...
> - 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.
In xosview you can just see the memory being marked "clear" :-)

> - 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?
I'm not sure about this... knowing the size of memory that we can use for
the generation gc (generation 1) may help, also we could lock that
generation in memory, as it _will_ be traversed anyway.

Just giving a hint to the OS (I'll need that page soon) should also be
handy.

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

There is no problem with the FP state, just that libc (used for math
functions) sends the program a SIGFPU when it detects an error. But it
doesn't fill in the fpu status word. So Lisp gets confused  :-(.

Groetjes, Peter

--
It's logic Jim, but not as we know it.
Look in keyservers for PGP key.
Version: 3.12
GS/CS/L/C d->? s+:++>+@ a-- C++(+++)>$ ULOS++>++++$ P+>++++ L+++>++++
E>++ W+(--) U++>+++ o>+ K? w--- O>+@ M-? V? PS++ PE(--) Y+ PGP+>++
t++>+++ 5++ X++>+++ R tv b+++>++++ DI++ D++@ G+>++ e++>++++ h!>+ r-@ y>+++**@