On Friday 09 January 2004 09:45, Sascha Brawer wrote: > Tom Tromey <[EMAIL PROTECTED]> wrote on Thu, 8 Jan 2004 17:48:59 -0700: > >[standard pluggable JIT interface] > > This would indeed be quite nice, IMHO.
IMHO2 (that should probably be 3 or 4 by now). I suspect that the interface to GC will be hard to define, though. There are several possible models, including: 1. The mutator (JITted code) tells GC, "hey! I just mutated something!", whereupon GC either (a) aborts the current attempt to mark the heap or (b) makes a note to re-mark the affected objects before doing a sweep. 2. No one is allowed to mutate anything during the marking process, so a protocol is devised which ensures this without deadlock. And that's only counting mark-and-sweep collectors ... > >Language choice for API. > > The obvious choices being: > > C lowest common denominator > > C++ next-to-lowest common denominator :-) provides some > > abstraction benefit, maybe > > Java using our own tools... > > There are some users of Classpath who cannot execute any C code, such as > Jaos and JNodeOS. If the pluggable JIT interface was in Java, these > systems would be able to use it (assuming that someone writes a JITter in > Java, like IBM did with their Jalapeņo/Jikes RVM). > > Also, I'd assume that the interface would be rather narrow in the sense > that it wouldn't get invoked very often in the direction VM --> JIT; > probably once for each class or method to be compiled. But the JIT would > presumably have to call a lot into the VM (for retrieving field offsets > etc.). > > >ABI Issues > > According to IBM's publications and web pages, Jikes RVM seems to nicely > cope with different ABIs (such as the slightly different calling > conventions for AIX and MacOS X). Maybe, their code could serve as an > example for how to structure the JIT interface so it can cope with > different ABIs. > > Jaos works on top of an abstraction called "object kernel", which > basically is an API to garbage collection, synchronization, etc. Patrik > Reali might be able to tell the list more about this. > > >General API > > > >- Verifier interface? > > Does the verifier do all checking or does it impose some > > requirements on the JIT/interpreter? (Some verifiers choose to > > delay some checking until interpretation.) > > Does the JIT want/need information already computed by the verifier? > > For instance basic blocks or the type map at a given statement. > > I think it would be very wasteful to compute this information twice, but > it might be very difficult to define common data structures that are > suitable for everyone. Might it be sufficient if a verifier could store > some opaque reference for later use by the JIT? > > AegisVM writes that they have developed a modular bytecode verification > architecture, but I didn't look at this yet. > > Another thing that might be interesting to share is parts of a compiler > backend, such as assemblers. > > -- Sascha > > Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ > > > > > _______________________________________________ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
