Mark Wielaard wrote: > Hi Graeme, > > 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. >>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. [thinking aloud: I don't think you could use subclassing to solve the problem, since if the common code is declared as the supertype (Object>Thread>VMThread) applications would need to call the constructor on the VM-type, and if it was the other way around (Object>VMThread>Thread) that would break the spec. for the common type.] >>In either case I think we want to determine how to build customized >>versions of a reference implementation without resorting to cut'n'paste >>duplication. IMO making the build process responsible for creating >>customized versions of VM-dependent classes from a master version puts >>the complexity in the right place (build-time vs runtime). > > > Yes, that is mostly how it works with GNU Classpath based runtimes. At > build time each runtime overrides/changes the few VMClasses for which it > cannot use the vm/reference version. This seems to work nicely and makes > it possible to share almost all of the glibj.zip classes as is. I'd claim that we both have the same goals of a small set of customized types. One solution was formulated at build-time and the other at runtime. Seems like a small distinction though, and the interop is simple enough. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
