[PATCH] 64-bit dtoa - strtod fix

[Christian Thalinger]

We are building a java jit called cacao
(http://www.complang.tuwien.ac.at/java/cacao/) which now uses the gnu
classpath. On our 64-bit ports we had problems with dtoa and strtod
functions. After a long night of debugging, i found the problem: it
seems that in mprec.h

#define MAX_BIGNUM_WDS 32

is too small for some floats. The amount can grow up to 48, as my
debugging showed. On i386 systems where Pack_32 is defined, it seems to
be ok. But Pack_32 does not work on 64-bit systems.

This bug is hit, when you try to execute this small code

class test {
public static void main(String[] argv) {
System.out.println(Double.MIN_VALUE);
}
}

with gij (gcc-3.3.2) on x86_64. Defining

#define MAX_BIGNUM_WDS 64

shows the expected result with our jit. I don't know if 64 is a
reasonable number, but when not packing 32-bit in a long but 16-bit,
twice as much should be ok.

This is also cross-posted to [EMAIL PROTECTED]

TWISTI

--- classpath-0.07/native/fdlibm/mprec.h2001-11-05
03:56:47.0 +0100
+++ cacaodev/gnuclasspath/native/fdlibm/mprec.h 2004-01-11
17:17:55.0 +0100
@@ -295,7 +298,12 @@


#define MAX_BIGNUMS 16
+
+#ifndef Pack_32
+#define MAX_BIGNUM_WDS 64
+#else
#define MAX_BIGNUM_WDS 32
+#endif

struct _Jv_Bigint
{




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch #2388] DefaultTableCellRenderer update

[Arnaud Vandyck]

Michael Koch <[EMAIL PROTECTED]> writes:

> This mail is an automated notification from the patch tracker
>  of the project: classpath.
>
> /**/
> [patch #2388] Latest Modifications:
>
> Changes by: 
>   Michael Koch <[EMAIL PROTECTED]>
> 'Date: 
>   Mon 01/12/04 at 12:03 (GMT)
>
> -- Additional Follow-up Comments 
> Some problems with this patch:
>
> - no changelog entry

And what is this?

 2003-12-01  Arnaud Vandyck  <[EMAIL PROTECTED]>

* javax/swing/table/DefaultTableCellRenderer.java
(DefaultTableCellRenderer): Added javadoc for the class and for
the constructor, Border instance, create an EmptyBorder.
(UIResource): Removed the comment at the end of the class
(setForeground): New method.
(setBackground): New method.
(updateUI): New method.
(getTableCellRendererComponent): rewritten with the help of
dvholten and Stephane Meslin-Weber.
(validate): New method.
(repaint): New method.
(firePropertyChange): New method.
(setValue): New method.


> - we dont wanna add stubbed methods anymore. Either implement it or leave it out.

Sorry if I left a stub method... Which one? Lot of methods in this
component are empty because they override parent and they DO NOTHING
(it's the way they are! because it's the table that make the renderer)

... if I understood it right! ;)

> /**/
> [patch #2388] Full Item Snapshot:
>
> URL: 
> Project: classpath
> Submitted by: Arnaud Vandyck
> On: Sun 11/30/03 at 23:22
>
> Category:  None
> Priority:  1 - Later
> Resolution:  None
> Assigned to:  None
> Originator Email:  
> Status:  Open
>
>
> Summary:  DefaultTableCellRenderer update
>
> Original Submission:  Here is a patch for 
> javax/swing/table/DefaultTableCellRenderer.java and here is the Changelog entry.
>
> 2003-12-01  Arnaud Vandyck  <[EMAIL PROTECTED]>
>
>   * javax/swing/table/DefaultTableCellRenderer.java
>   (DefaultTableCellRenderer): Added javadoc for the class and for
>   the constructor, Border instance, create an EmptyBorder.
>   (UIResource): Removed the comment at the end of the class
>   (setForeground): New method.
>   (setBackground): New method.
>   (updateUI): New method.
>   (getTableCellRendererComponent): rewritten with the help of
>   dvholten and Stephane Meslin-Weber.
>   (validate): New method.
>   (repaint): New method.
>   (firePropertyChange): New method.
>   (setValue): New method.
>
>
> Follow-up Comments
> --
>
>
> ---
> Date: Mon 01/12/04 at 12:03 By: mkoch
> Some problems with this patch:
>
> - no changelog entry
> - we dont wanna add stubbed methods anymore. Either implement it or leave it out.
>
>
>
>
>
>
> File Attachments
> ---
>
> ---
> Date: Sun 11/30/03 at 23:22  Name: DefaultTableCellRenderer.patch  Size: 4KB   By: 
> avdyk
>
> http://savannah.gnu.org/patch/download.php?item_id=2388&item_file_id=2407
>
>
>
>
>
>
> For detailed info, follow this link:
> 
>
> ___
>   Message sent via/by Savannah
>   http://savannah.gnu.org/
>
>
>
>

-- 
Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch #2388] DefaultTableCellRenderer update

[Michael Koch]

On Mon, Jan 12, 2004 at 03:32:35PM +0100, Arnaud Vandyck wrote:
> Michael Koch <[EMAIL PROTECTED]> writes:
> 
> > This mail is an automated notification from the patch tracker
> >  of the project: classpath.
> >
> > /**/
> > [patch #2388] Latest Modifications:
> >
> > Changes by: 
> > Michael Koch <[EMAIL PROTECTED]>
> > 'Date: 
> > Mon 01/12/04 at 12:03 (GMT)
> >
> > -- Additional Follow-up Comments 
> > Some problems with this patch:
> >
> > - no changelog entry
> 
> And what is this?
> 
>  2003-12-01  Arnaud Vandyck  <[EMAIL PROTECTED]>
> 
>   * javax/swing/table/DefaultTableCellRenderer.java
>   (DefaultTableCellRenderer): Added javadoc for the class and for
>   the constructor, Border instance, create an EmptyBorder.
>   (UIResource): Removed the comment at the end of the class
>   (setForeground): New method.
>   (setBackground): New method.
>   (updateUI): New method.
>   (getTableCellRendererComponent): rewritten with the help of
>   dvholten and Stephane Meslin-Weber.
>   (validate): New method.
>   (repaint): New method.
>   (firePropertyChange): New method.
>   (setValue): New method.

Oh, I totally overlooked this.

> 
> 
> > - we dont wanna add stubbed methods anymore. Either implement it or leave it out.
> 
> Sorry if I left a stub method... Which one? Lot of methods in this
> component are empty because they override parent and they DO NOTHING
> (it's the way they are! because it's the table that make the renderer)
> 
> ... if I understood it right! ;)

If thats the case the you should really add this as comment to method
like this:

public void foobar()
{
  // This methods needs to be overridden in subclasses to actually do
  // somthing.
}

A comment in the method documentation can't hurt too but "Does nothing."
is a little bit short and undesciptive why this method does nothing.


Michael


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch #2388] DefaultTableCellRenderer update

[Michael Koch]

On Mon, Jan 12, 2004 at 04:18:00PM +0100, Arnaud Vandyck wrote:
> Michael Koch <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Jan 12, 2004 at 03:32:35PM +0100, Arnaud Vandyck wrote:
> >> Michael Koch <[EMAIL PROTECTED]> writes:
> >> > - no changelog entry
> >> And what is this?
> [...]
> > Oh, I totally overlooked this.
> NP.
> 
> >> > - we dont wanna add stubbed methods anymore. Either implement it or
> >> > leave it out.
> >> 
> >> Sorry if I left a stub method... Which one? Lot of methods in this
> >> component are empty because they override parent and they DO NOTHING
> >> (it's the way they are! because it's the table that make the renderer)
> >> 
> >> ... if I understood it right! ;)
> >
> > If thats the case the you should really add this as comment to method
> > like this:
> >
> > public void foobar()
> > {
> >   // This methods needs to be overridden in subclasses to actually do
> >   // somthing.
> > }
> >
> > A comment in the method documentation can't hurt too but "Does nothing."
> > is a little bit short and undesciptive why this method does nothing.
> 
> Yes, I should comment, sorry. The fact is some methods in this component
> are overriden because it's the table that does redraw all the components
> and if each component redraw it self, it'll take too much time.
> 
> I thing I still have some mails that explain exactly what happens (some
> devs on this list helped me).
> 
> You know Mark, it took me a long time to understand and to implement
> (event empty methods because I was not sure I have to leave it empty)
> and I really want a working swing implementation, not just a library to
> compile (but not to run). Believe me, when I do send a patch, I try that
> it's really useful ;)... even if I make mistakes ;)
> 
> I already do follow your coding standards, next time, I'll comment my
> code ;)

No problem. Will you update your patch or should I do it ? Then the
patch can go in.


Michael


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch #2388] DefaultTableCellRenderer update

[Arnaud Vandyck]

Michael Koch <[EMAIL PROTECTED]> writes:

> On Mon, Jan 12, 2004 at 03:32:35PM +0100, Arnaud Vandyck wrote:
>> Michael Koch <[EMAIL PROTECTED]> writes:
>> > - no changelog entry
>> And what is this?
[...]
> Oh, I totally overlooked this.
NP.

>> > - we dont wanna add stubbed methods anymore. Either implement it or
>> > leave it out.
>> 
>> Sorry if I left a stub method... Which one? Lot of methods in this
>> component are empty because they override parent and they DO NOTHING
>> (it's the way they are! because it's the table that make the renderer)
>> 
>> ... if I understood it right! ;)
>
> If thats the case the you should really add this as comment to method
> like this:
>
> public void foobar()
> {
>   // This methods needs to be overridden in subclasses to actually do
>   // somthing.
> }
>
> A comment in the method documentation can't hurt too but "Does nothing."
> is a little bit short and undesciptive why this method does nothing.

Yes, I should comment, sorry. The fact is some methods in this component
are overriden because it's the table that does redraw all the components
and if each component redraw it self, it'll take too much time.

I thing I still have some mails that explain exactly what happens (some
devs on this list helped me).

You know Mark, it took me a long time to understand and to implement
(event empty methods because I was not sure I have to leave it empty)
and I really want a working swing implementation, not just a library to
compile (but not to run). Believe me, when I do send a patch, I try that
it's really useful ;)... even if I make mistakes ;)

I already do follow your coding standards, next time, I'll comment my
code ;)

Cheers,

-- 
Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: [patch #2388] DefaultTableCellRenderer update

[Arnaud Vandyck]

Michael Koch <[EMAIL PROTECTED]> writes:

> No problem. Will you update your patch or should I do it ? Then the
> patch can go in.

As you want (if you can do it, go on ;)). I don't think I'll have the
time to do that but maybe we'll meet tonight (for me at last) on #kaffe
;) Also, I don't know if I still have the patch on my machine (and were
it is!)... and I don't have a classpath cvs in sync... (yes, I know,
it's a shame!)...

Cheers to everyone,

-- 
Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programmation.


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: JIT pluggability (ABI Issues)

[Patrik Reali]

ABI Issues.

I would divide this in three parts: allocation, calling convention, code 
patterns.

Allocation deals with the addresses of the data structures and is fairly 
easy to deal with. The information needed is:
* size for each basic type
* padding/alignment of each type (in an object, in an array)
* class layout (do we really need this? I guess the fields are allocated in 
the row as they are declared)
* class hidden fields (type descriptor, locks, ...)
* array layout (this may get complicated)
* method number / offset in the vtable or itable
* class numbering / interface numbering (for the systems that use this 
information)
* Strings (some systems may have some special implementations here)

Calling Convention
* left-to-right (as in java) or right-to-left (as in C)
* self (first or last?)
* size and alignment issues
* return values (on register? on stack?)
* which params are passed on stack / in a register
* register saving policies
Code Patterns (using a system call or some inlined code)
* method invocation (i.e. type descriptor layout)
* class allocation
* array allocation
* class initialization
* locking / unlocking
* switch-tables (Jaos has a table with the absolute address of each switch 
destination, this must be patched by the linker)
[... I'm sure I'm missing some here...]

I think allocation is fairly simple to deal with. In fact, each backend 
could provide an implementation class which computes the allocation values.

Calling convention and code pattern configuration may make even the 
simplest compiler become too complex to implement please correct me if 
wrong (this is just an assumption).

-Patrik


Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos/
http://iiop-net.sourceforge.net/


--On Freitag, 9. Januar 2004 09:45 +0100 Sascha Brawer <[EMAIL PROTECTED]> 
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.

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

Re: JIT pluggability (GC Interface)

[Chris Gray]

On Monday 12 January 2004 21:11, Patrik Reali wrote:
> Hi!
>
> let me add my 0.02 cents (of euro). :-)

Yup, it's "soldi" time. :)

> GC Interface:
>
> let's divide the GCs in 2x2 categories:
>
> * (TA) type-accurate: know where the pointers inside the objects are
> * (CO) conservative: guess where the pointers inside the objects are
>
> and
>
> * (NC) non-concurrent: the GC is the only thread running during the
> collection
> * (CI) concurrent / incremental: the GC and the mutator run
> (pseudo-)concurrently

CI corresponds to my type 1, NC to type 2.

> These categories affect the interface between compiler, generated code, and
> the gc itself.

Is anybody using CO?

> Static information (TA vs. CO):
> * All GCs need a hook into the memory management to return the blocks to
> the free-list.
> * All GCs need to access the whole heap
> * TA GCs need a root-set from which the collection starts: the list of all
> static fields, all pointers on the stack of each thread, all pointers in
> the CPU registers (and those in the stack when the thread is preemted) [The
> registers depend in fact on the compiler optimizations: if some value may
> live longer in a register than in a variable then yes, otherwise if the
> compiler ensures that all pointers in the registers are also anchored
> somewhere in a variable, then no]
> The list of static fields can be obtained through reflection; pointers on
> the stack are more complicated to get.
> * TA GCs need a type descriptor containing the pointer offsets inside each
> type; arrays of references are also to be collected
>
> Code Instrumentation (NC vs. CI):
> * NC GCs do not need code instrumentation

Not so fast.

A NC GC typically needs to bring all (non-GC) threads to a "safe" state 
before it can run: a "safe" state is one in which all references from a 
thread to the heap are visible to GC. So some degree of instrumentation is 
needed in order to determine when a thread is "safe", and maybe also a 
mechanism to politely ask a thread to become "safe" at the earliest 
opportunity.
 
> * some CI GCs define code points where the GC can run
> * some CI use read barriers (each pointer read operation is instrumented)
> * some CI use write barriers (each pointer store operation is instrumented)
> * some GCs use master-lists (each pointer points to the real pointer which
> is present only once, thus moving an object correspond to moving a
> master-pointer instead of each reference)

AKA "handles".

>
> Example: Jaos + Aos Kernel
> The Aos kernel provides memory allocation with a mark & sweep GC; the mark
> operation is implemented using the pointer rotation algorithm (Deutsch
> Waite Schorre). This is a "stop the world" non-concurrent GC (even in the
> multiprocessor version of the kernel).
> The GC information is provided by the Jaos classloader (because it performs
> the field allocation during the load); each class has a module (a runtime
> compilation-unit) with the code, statics and a list of static pointers, and
> a type descriptor containing the pointer offsets, the method table, and the
> type hierarchy (those are then patched by the linker). The stack traversal
> is conservative.
>
> A few pointers:
> * http://www.memorymanagement.org
> * Paul Wilson; Uniprocessor Garbage Collection Techniques; Proceedings of
> the Memory Management, International Workshop, Saint Malo, France, Sep 1992
> (postscript 764KB; ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps)
> * Garbage Collection in Oberon: http://www.oberon.ethz.ch/gc/
> * Garbage Collection in .NET: (part 1)
>  and (part 2)
>  2/GCI2.asp>
> * Slides from lecture "System Software" on Garbage Collection:
> http://www.cs.inf.ethz.ch/37-201/slides/ssw03_memorymanagement_2.pdf

And if you don't mind killing trees: Richard Jones, Rafael Lins; Garbage 
Collection; John Wiley and Sons, 1996 (ISBN 0 471 94148 4).

> I hope this clarifies more than it confuses
>
> -Patrik
>
>
> --On Samstag, 10. Januar 2004 11:29 +0100 Chris Gray <[EMAIL PROTECTED]>
>
> wrote:
> > 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 ...

Re: JIT pluggability (ABI Issues)

[Per Bothner]

Patrik Reali wrote:

Calling Convention
* left-to-right (as in java) or right-to-left (as in C)
Huh?  Argument evaluation order is not really part of the ABI.
C has *unspecified* evaluation order, so many implementations
have evaluated them right-to-left because that's the way the
stack grows (on most C implementations).  But this is less
relevant with optimizing compilers and register-based calling
conventions.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: JIT pluggability (GC Interface)

[Patrik Reali]

Hi!

let me add my 0.02 cents (of euro). :-)

GC Interface:

let's divide the GCs in 2x2 categories:

* (TA) type-accurate: know where the pointers inside the objects are
* (CO) conservative: guess where the pointers inside the objects are
and

* (NC) non-concurrent: the GC is the only thread running during the 
collection
* (CI) concurrent / incremental: the GC and the mutator run 
(pseudo-)concurrently

These categories affect the interface between compiler, generated code, and 
the gc itself.

Static information (TA vs. CO):
* All GCs need a hook into the memory management to return the blocks to 
the free-list.
* All GCs need to access the whole heap
* TA GCs need a root-set from which the collection starts: the list of all 
static fields, all pointers on the stack of each thread, all pointers in 
the CPU registers (and those in the stack when the thread is preemted) [The 
registers depend in fact on the compiler optimizations: if some value may 
live longer in a register than in a variable then yes, otherwise if the 
compiler ensures that all pointers in the registers are also anchored 
somewhere in a variable, then no]
The list of static fields can be obtained through reflection; pointers on 
the stack are more complicated to get.
* TA GCs need a type descriptor containing the pointer offsets inside each 
type; arrays of references are also to be collected

Code Instrumentation (NC vs. CI):
* NC GCs do not need code instrumentation
* some CI GCs define code points where the GC can run
* some CI use read barriers (each pointer read operation is instrumented)
* some CI use write barriers (each pointer store operation is instrumented)
* some GCs use master-lists (each pointer points to the real pointer which 
is present only once, thus moving an object correspond to moving a 
master-pointer instead of each reference)

Example: Jaos + Aos Kernel
The Aos kernel provides memory allocation with a mark & sweep GC; the mark 
operation is implemented using the pointer rotation algorithm (Deutsch 
Waite Schorre). This is a "stop the world" non-concurrent GC (even in the 
multiprocessor version of the kernel).
The GC information is provided by the Jaos classloader (because it performs 
the field allocation during the load); each class has a module (a runtime 
compilation-unit) with the code, statics and a list of static pointers, and 
a type descriptor containing the pointer offsets, the method table, and the 
type hierarchy (those are then patched by the linker). The stack traversal 
is conservative.

A few pointers:
* http://www.memorymanagement.org
* Paul Wilson; Uniprocessor Garbage Collection Techniques; Proceedings of 
the Memory Management, International Workshop, Saint Malo, France, Sep 1992 
(postscript 764KB; ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps)
* Garbage Collection in Oberon: http://www.oberon.ethz.ch/gc/
* Garbage Collection in .NET: (part 1) 
 and (part 2) 

* Slides from lecture "System Software" on Garbage Collection: 
http://www.cs.inf.ethz.ch/37-201/slides/ssw03_memorymanagement_2.pdf

I hope this clarifies more than it confuses

-Patrik

--On Samstag, 10. Januar 2004 11:29 +0100 Chris Gray <[EMAIL PROTECTED]> 
wrote:

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