turner at email.enst.fr
Tue Sep 30 03:57:24 PDT 1997
I'm working on a real-time implementation of Kaffe, and I'd like to know
if some efforts have already been deployed in this direction. I target
mainly the RTEMS real-time kernel and NT ( in a pseudo-real-time mode, of
course ). I've already started studying Kaffe's source code ( 0.9.1 )
and adding some changes. I have already some problems :
- thread management :
the potential for native threads have been introduced in 0.9.1,
but this package lacks some important parts.
One remarkable thing is the use of the global variable "currentThread"
to access, well.. as you may guess, the current running thread. This
is inadequate for a real native threads implementation.
A hard problem is that the Jit itself relies on this variable, in
in-line assembly routines ! If this were not the case, it would be
trivial to begin by redefining "currentThread" as a macro that calls
the correct function.
I'm thus obliged to work with the interpreter.. Or rewrite some
parts of the Jit. Even though I could do it for i386, I'm unable
to touch the code for the Sparc and 68K..
There are some other minor issues that can be fixed easily (and I
already did for some).
That's why I'm asking if a real native threads implementation
is planned soon ? Or will I have to stick with the interpreter ?
- real-time garbage collection
It seems that the incremental garbage collector isn't finished yet.
It is clearly needed for a real-time implementation. The gc in Kaffe
seems really great and I'm convinced that there aren't a lot of work
to make it work, but I'm unable for the moment to tell exactly where
( still studying though ). Has anyone started this work already ?
Or should I dive in Kaffe's internals to change it myself ?
Just as a side-note, I have chosen the following scheme for
thread and memory-management :
- all ordinary Java threads are implemented on one
kernel task ( either a RTEMS task or NT kernel thread )
and scheduled internally by the Jvm
- however, each real-time thread is implemented on its
own kernel task. This allows several useful things. The
main one being that it is possible to block all ordinary
threads during a garbage collection operation, while keeping
the real-time threads alive and kicking. This can lead to
better performance and reduced memory over-conservatism compared
to a purely incremental GC.
I have thus made changes to the locks, threads, exception, etc..
components to implement this hybrid scheme. I know need to make
the GC incremental wrt the real-time threads only, but not the
In the event that you think that this scheme is doomed to failure
due to Kaffe's current implementation (or other technical reasons ;-)
don't hesitate to contact me.. I'm opened to all suggestions..
I can also upload my changes, but I fear they're not very useful
I just hope that someone is already working in this kind of direction,
and I'd really like to collaborate..
turner at enst.fr
PS: I'm not on the list yet, please reply also to me by standard email
More information about the kaffe