I was reminded off-list that Jikes RVM's use of GNU classpath's VM/library
interface was more complex than I'd described in my previous note. The
Foo/VMFoo works quite nicely for us in many cases, especially when the
VMFoo class is a holder for VM-specific static methods (eg, VMRuntime,
VMSyst
Yes. The main focus of the Jikes RVM project is VM/JIT research. We've
made minor contributions to the design of the GNU classpath VM/classlib
interface, since we are one of the many runtimes that depend on it, but
we're mainly consumers of class libraries, not producers. As discussed in
more
> > 3. Don't worry about inlining Java code: assume the VM can do 'easy'
> >inlining like invoking static methods.
>
> How does that aspect matter to the VM/classlib interface?
>
It matters in that when defining the VM/classlib interface you
should assume that adding a level of "eas
take a look at the javadoc (http://jikesrvm.sourceforge.net/api/). That
should be "mostly harmless" from a contamination perspective.
--dave
Jikes RVM has similar kinds of abstractions, but in Java of course ;-)
It's a pretty wide API since there are lots of things the JIT wants to
know about the program being compiled.
The javadoc for the system is online at
http://jikesrvm.sourceforge.net/api/index.html. The package of interest
[EMAIL PROTECTED] wrote on 06/05/2005 10:48:29 PM:
> - The machine code concatinating technique consumes much memory.
> In my experience, generated machine code is about 10 times larger
> than the original instructions in Java bytecode.
>
> In the paper, the authors have not mentioned memory
>From a user perspective, Jikes RVM uses classpath "out of the box". (It
builds with unmodified GNU classpath releases and classpath cvs head; we
don't distribute GNU classpath with Jikes RVM).
We do provide our own versions of a few classes in java.* that the build
process selects instead of
