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 Wed, 09 Nov 2005 14:14:43 GMT
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.



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

View raw message