New Blog Post on VM Interfaces

[Andrew John Hughes]

2008/7/29 David Holmes - Sun Microsystems <David.Holmes at sun.com>:
> Hi Andrew,
>
> Another dimension to this "VM interface" issue is determining when a library
> requires VM support and when it just need native support. For example
> Object.wait needs VM support, but I/O normally just needs native support ...
> except it isn't that clear cut because if we take for example the infamous
> "interruptible I/O" on Solaris we find that some I/O operations have to go
> through the VM to get the interruption support. So a future change in
> semantics might change whether a library needs VM support or just native
> support.
>

Indeed.  Things like the AWT peers are obvious examples of this;
native code that it makes
no sense for the VM to reimplement.  I/O tends to be the middle
ground, and, off the top of my head, I think we also
have a mix of VM and non-VM native stuff in there for GNU Classpath too.

I think any VM interface is always going to be fairly fluid and will
evolve as the class library
changes or as new VM requirements become apparent.  What I hope with
this project is that
OpenJDK can speed up the evolution of its own VM interface by learning
from the same lessons
as GNU Classpath, avoiding making the same mistakes and becoming a
well documented and
general VM interface sooner.

One of the big differences (actually mentioned quite well in the
slides Mark just posted about) is that
GNU Classpath has had to deal with a lot of abnormal VMs (JikesRVM,
IKVM.NET, GCJ) where a
simple C-based VM interface isn't the best solution. Maxine, the Sun
Java-based research VM, currently
has to special-case methods to get around the fact that they are
defined as native.  Defining methods as
native leaves no other options but to either go the native route or
hack around it in the VM.  With a Java-based
VM interface, more options are available, while a C-based interface is
just an extra hop away.  It also
seems intrinsically self-documenting if there are specific VM classes.
 This is why I believe this to be one of
the early goals of this project.

> In a sense every native method can potentially interface to the VM,
> depending on what the actual C code does. This makes things a bit
> inconsistent in Classpath where the VMxxx classes define the VM interface
> layer, but the direct use of native methods defines another implicit
> interface layer.

True, but there's always going to be an element of how 'correctly' a VM
follows the interface path.  I'd regard this as a bug in the VM interface i.e.
it's not suitable to deal with the case and the VM has to work around the
interface.  We've fixed such bugs in GNU Classpath before, and again this
is part of the interface evolution.

 When I worked on the OVM project (Jan Vitek at Purdue -
> 2001-2004) we actually had to redirect may of those native methods back into
> the VM because we had a single-native-thread and so had to use non-blocking
> I/O within that thread. We would have preferred if instead of native methods
> every class delegated to a VMxxx class first and that it then could define
> Java or native methods as required (just as VMObject et al do). I don't know
> if Classpath eventually moved to this level of moving every native method
> into a VMxxx class?
>

Yes, GNU Classpath is pretty much at this level now, mainly pushed by the likes
of JikesRVM and JNode.

> Now for OpenJDK, without rewriting the Java code to call VMxxx methods you
> could say that native methods are the interface layer and that the C code
> can then either delegate to a JVM_xxx method or else use a direct
> implementation. Or you could define a JVM_xxx method for every native call
> and have a default implementation that provides a simple/direct C
> implementation or else calls a "real" VM method. But you end up with a very
> fat interface layer.
>

The first case you mention is pretty much the status quo now.  There are lots of
native methods in the class libraries, and some are redirected (via
registerNatives)
to JVM_xxxx.  These remains as unresolved symbols in the dynamic
libraries produced
and are resolved against the VM at runtime.

> Anyway just some comments ...
>

Thanks, much appreciated.

> Cheers,
> David Holmes
> Senior Java Technologist
> Java SE VM Real-time and Embedded Group
> ---------------------------------------
>
> Andrew John Hughes said the following on 07/29/08 07:25:
>>
>>
>> http://blog.fuseyism.com/index.php/2008/07/28/comparing-and-contrasting-vm-interfaces/
>

--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8