harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Tue, 15 Nov 2005 12:56:50 GMT
Mark Wielaard wrote:
> Right. It might be instructive to participate in the discussion started
> this week about the newly proposed network VM interface classes
> suggested by Ingo and Roman on the classpath-patches mailinglist.
> http://lists.gnu.org/mailman/listinfo/classpath-patches
> (Subject "RFC: new VM interface for Socket impls")

Thanks for the pointer -- I read the thread and still think that whether
the VM classes are a customized class replacement or a customized class
delegate makes little difference.

> To give you a quickstart let me explain the design criteria. The VM
> interface class has to be high-level enough to be usable/optimizable for
> a runtime that doesn't use C/Posix/JNI (as preferred platform/runtime
> interface).

Sure.

> GCJ for example uses CNI which provides a ABI bridge between
> c++ and java classes (which has a completely different performance
> trade-off then JNI. Class field accesses are cheap with CNI since they
> are just direct references, while in JNI they are expensive). IKVM.NET
> for example would wrap the System.Net.Sockets classes to implement the
> above VM interface.

I read the description of CNI here:
	http://gcc.gnu.org/onlinedocs/gcj/index.html

Is there some description of how this looks from the Java side?  Are the
natives declared as CNI natives somehow, or does the VM go through the
regular JNI dispatch (building a JNIEnv, function name mangling etc) to
call the CNI method.  Once in the native code I see how the unified
object model works.

How does the existence of this calling convention affect the choice of
kernel types?  I agree there will be different characteristics for
kernel types written in JNI, CNI or Java, but since we agree that the
replacement is at a Java class level then I don't yet see how this is so
relevant.

> Besides that there has to be at least one concrete
> vm/reference implementation based on C/Posix/JNI (which is hopefully
> properly autoconfed to make it portable across most modern GNU/Unix-like
> platforms). This reference implementation should in principle work out
> of the box for runtimes implementing JNI and that don't want to make any
> specific platform/runtime optimizations.

Right, and I'm guessing that the CNI is equally applicable in any area
of the class library that uses native code, so people are free to choose
JNI or CNI at any place (assuming gcj/G++).

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message