harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Sat, 12 Nov 2005 15:28:57 GMT
Hi Tim,

On Wed, 2005-11-09 at 14:14 +0000, Tim Ellison wrote:
> Mark Wielaard wrote:
> > On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote:
> >>Split-class (ClassX & VMClassX) or customized-class solutions (Tim E's 
> >>Kernel classes) are different approaches to solving the same problem.
> > 
> > Not completely. I think they complement each other. The ClassX &
> > VMClassX split describes at a high (java) level what the
> > responsibilities of an runtime/execution-model are. Then the VMClasses
> > are more like the customized-class solutions in case you have a
> > traditional execution-model that is based on JNI/Posix like platforms.
> I'm assuming that ClassX and VMClassX are quite closely coupled, so that
> other types in the package don't make internal API calls on VMClassX
> directly?  If that is true it's also worth pointing out that the (ClassX
> + VMClassX) combination will simply look like a kernel version of ClassX
> to the rest of the classlibrary code -- it's a pretty minor difference
> at that level.

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.
(Subject "RFC: new VM interface for Socket impls")

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). 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. 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.

> >>Of the two approaches I believe that the customized-class solution 
> >>delivers simpler code and shorter call-paths as it avoids the need for 
> >>any runtime redirection.
> > 
> > That can be an issue indeed. But by marking the VMClasses package
> > private and final (or just have list in the jit/compiler) all calls to
> > them should be able to be optimized away if needed.
> Agreed.  What you are pointing out is that the JIT will roll the code
> defined in two classes into the moral-equivalent of one class anyway ;-)
> Most JITs will do the method inlining out of the box, and the same thing
> could happen for storage too if the VM/JIT is aware of the pattern --
> the VM/JIT could allocate storage for the common code and delegate
> contiguously; and make that assumption.  Without such an awareness you
> would require two objects, with a read-barrier to access the delegate,
> and may suffer from data locality probs if they end up miles apart.

Yes, but note that not all free runtimes/compilers do this class/vmclass
inlining yet (gcj for example doesn't do it and the various interpreters
also don't do it). And except in some contrived micro-benchmarks it
doesn't even seem to show up in the profiling data. So it is an
optimization to keep in mind because it could impact performance, but it
isn't the first optimization you need to implement to get good
performance in most real world applications (except probably for
Object/VMObject and Class/VMClass but those are often handled specially
inside the runtime/execution mechanism anyway).



Escape the Java Trap with GNU Classpath!

Join the community at http://planet.classpath.org/

View raw message