Kaffe stack bounds checks

[golubovsky at altavista.net]

On Mon, 23 Aug 1999, Godmar Back wrote:

>
>Could you elaborate on what you're doing here?  Your description confused
>me somewhat.  Are you or are you not using linux's clone(2) system call?
>If not, why exactly is it that you can't?  What are copy-on-read pages
>anyway?

Anyway that's my mistype: of course I meant Copy-On-Write ... My apologies to
everybody.

I use the clone(2) syscall but I have to clone memory in order to have
separate stacks (and other process private areas). I'm against pthread-like
thread concept because in that way I cannot control which memory is common and
which is private; I can with shared memory and fork/clone. I mentioned that to
show why I cannot avoid larger cost of thread creation. Using threads with
entirely shared memory we may use clone(2) without copying page descriptors
(pthreads do so); this leads to a problem of stacks separation raised in one
of previous messages.

Some words about my work. I abstained from publishing information about it
widely before just because of design's very unstable and early state. Now I
can tell something to the public (and in the same time to hear from people
about needs in such a design).

My goal is to create a whole Java-bytecode based environment for the Linux
kernel. In my current design I utilize some Linux-specific things like
clone(2) and kernel calls. However I think that any kernel with similar
syscalls system may be suitable for this design in future.

After my graduation (in 1989) I worked for several years as a realtime
assembly programmer. That's why I'm sure that interpreter loop itself and
simpliest (and most frequent) instructions should be implemented in assembly.

By using direct syscalls invocation I hope to get rid of native code as much
as possible. I don't implement any kind of published native interface but my
own instead; only limited number of native methods is hardcoded into the VM
executable. User's classes are not allowed to load native libraries (like in
JavaOS).

I try to get rid of libc (disappointed by libc5 and libc6 conflicts, I'd
rather borrow some necessary code from libc than make my program dependent of
library versions; anyway the part of libc interesting for me is just a wrapper
for kernel calls). Also Java classes have a rich library of functions which
mostly substitutes libc.

I've already described my understanding of thread concept. I use %esp as a
Java sp, %esi as pc, %ebp as frame pointer, %edi holds instruction bytecode
address (in order to handle exceptions), rest registers are available for
computations. Of course this is possible only when the interpreter loop is
coded in assembly. Some years ago I had some experience with Forth, and my
interpreter is built on the same principle as Forth interpreter (which
traditionally is coded in assembly). Instructions may be implemented both in
assembly and in C; some assembly-implemented instructions call C routines.
Usually those instructions which deal with VM memory structures are
implemented in C. The simpliest ones like integer arithmetics and stack
manipulation are coded in assembly.

I consider this way as a JIT alternative. I don't think that I'll outperform
Kaffe JIT (however I'll try to measure the difference when it will be
possible). But growing clock frequency of contemporary CPU's makes this
problem less and less significant. Unfortunately Intel CPU isn't the best
platform for JVM implementation at all; RISC with several tens of registers
might allow, say, to allocate method's frame and maybe part of stack on
registers and make VM faster.

As a result with approx. 70% of instructions implemented (partly or
completely) my statically linked executable is about 96k in size. I don't
expect it to grow larger than 150k.

Of course essential part of this design is Java class tree which I borrow from
Kaffe. Some classes undergo changes like rewriting some native methods in
Java.

I cannot even tell when this project will get some final shape. Now I'm able
to execute something like "Hello World" using syscalls, not streams. The next
goal is to execute at least 50% of tests supplied with Kaffe.

Dmitry M. Golubovsky
      St-Petersburg, Russia