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. http://lists.gnu.org/mailman/listinfo/classpath-patches (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). Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
