Re: CMUCL's kernel requirements (long&educational)

[William.Lott@CS.CMU.EDU]

Alessandro.Forin@SPICE.CS.CMU.EDU writes:
...
> d) In Mach I decided that if a page had the VM_PROT_EXECUTE permission
> it contained text, regardless of its location in the address space.
...
> e) In Mach 2.5 vm_allocate() creates pages that have the EXECUTE bit on,
> and this is (in retrospect) an oversight on my side.  The cost on a pmax
> for flushing the Icache on a zero-fill page fault (e.g. when you first
> touch a vm_allocated page) is very great, over 30% of the total cost.
> And zero-filling is a major fraction of, for instance, compilation of a
> C program.
...
> h) In Mach 3.0 the default VM protection does not include execute
> permission, sparing me that 30% hit.  If a program does what lisp
> does, it must vm_protect(2) appropriately the memory where it puts
> instructions.

It looks to me as if we have several options here.  We can do as you
suggest and add the execute protection bit to the entire lisp heap,
but that would cost us the 30%.  Would the following work, and if so,
would it be better?

- Allocate the heap without the execute bit.
- After a code object is created, but before it is executed, use
vm_protect to add the execute bit (to assure that the I-cache will be
flushed if it gets paged out and back in someplace else), and flush it
from the I-cache (it was zero-filled before the execute bit was there,
so this won't happen automatically).
- When we GC, allocate newspace without the execute bit, do the GC,
then vm_protect and flush the part of newspace we have written,
avoiding the I-cache flush hit on each zero-fill.  (We don't want to
do this on a per code object basis after a GC, 'cause there will be
*lots* of code objects ``created'' during GC).

The other option is to have special spaces for code objects, but that
would be a more extensive change.

-William