Real-Time Kaffe

David Turner turner at
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
        ordinary ones.
        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..
 Best regards
 - David
   turner at

PS: I'm not on the list yet, please reply also to me by standard email

More information about the kaffe mailing list