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.

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/

Mime
View raw message