[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JIT pluggability
Re: JIT pluggability
Sat, 10 Jan 2004 11:29:42 +0100
On Friday 09 January 2004 09:45, Sascha Brawer wrote:
> Tom Tromey <address@hidden> 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
> >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, address@hidden, http://www.dandelis.ch/people/brawer/
> Classpath mailing list
Chris Gray /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi http://www.kiffer.be/k/
address@hidden +32 477 599 703
Re: JIT pluggability, Artur Biesiadowski, 2004/01/09
Re: JIT pluggability, Niranjan Suri, 2004/01/10
- JIT pluggability, Tom Tromey, 2004/01/08
- Re: JIT pluggability, Sascha Brawer, 2004/01/09
- Re: JIT pluggability (ABI Issues), Patrik Reali, 2004/01/12
- Re: JIT pluggability (ABI Issues), Chris Gray, 2004/01/13
- Re: JIT pluggability (ABI Issues), shudo, 2004/01/13
- Re: JIT pluggability (ABI Issues), Sascha Brawer, 2004/01/13