Kaffe stack bounds checks

golubovsky at altavista.net golubovsky at altavista.net
Sun Aug 22 22:30:43 PDT 1999



On Sun, 22 Aug 1999, William E. Cohen wrote:

>It is possible to make the memory protection hardware in the processor
>perform the stack bounds check.  Before and after each stack have a
>page of memory marked as unaccessable.  If there is an stack access
>beyond the bounds of the stack it would fall on one of the
>unaccessible pages, a SIGSEGV signal would occur.  Linux, Solaris, and
>DEC Unix all have a function mprotect that can be used for that
>purpose.  This approach uses more memory, but I think that most people
>would be willing to trade memory for more speed.

Has anyone tried the approach I use for design of my Java bytecode VM (where I
borrow Kaffe's classes)? I implement threads as separate Linux processes;
common memory pool is created as a big chunk of shared memory (Linux currently
allows only 32M for a single chunk; I suppose this may be avoided by minor
kernel patching if necessary). Shared memory is inherited after clone().
Therefore we have stacks separated by OS, and this is OS responsibility to
reallocate them and protect them. I couldn't find in the JVM specification any
reason to have possibility of reference from one process (thread) to another
process' stack.

I suppose that any OS which supports shared memory in the same style will be
compatible with this approach.

Advantages: non-reentrant library calls are usable (however I try to get rid
of libc at all; kernel calls are reentrant) because we control which part of
process' space is shared and which is private, Java stack is same as native
stack (but I need to implement interpreter's loop in assembly).

The most significant disadvantage of this approach is larger cost of thread
creation. This is because with Copy-On-Read pages, we have to copy just page
descriptors whose number is in the direct proportion to the shared memory
amount. I cannot set the flag CLONE_VM in order to have separated stacks. 

I've made some measurements on Celeron 300 (375 is actual clock) with 128M
RAM.

Some measurements are shown below:

Shared MB       Clone()'s/sec

1               4664.331391
2               4010.008983
3               3486.628779
4               3114.255818
5               2795.380912



More information about the kaffe mailing list