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 Wed, 09 Nov 2005 10:59:54 GMT
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.

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

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



Escape the Java Trap with GNU Classpath!

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

View raw message