harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Johnson <Graeme_John...@ca.ibm.com>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Mon, 07 Nov 2005 22:03:15 GMT
Mark Wielaard <mark@klomp.org> wrote on 11/05/2005 05:56:59 AM:

> Hi Rodrigo,
> On Fri, 2005-11-04 at 17:53 -0200, Rodrigo Kumpera wrote:
> > I see 2 options here:
> > 
> > -Allow for some implementation stuff to package private
> > -Have a org.apache.harmony, or something else, package tree where all
> > implementation stuff will reside.
> > 
> > In the first case, only trusted code will be allowed to access such
> > code by using reflection. Otherwise the SecurityManager will stop it.
> > 
> > In the second case, we will need some classloading hacks to forbid
> > application code to access public classes on the org.apache.harmony
> > tree.
> Indeed. And it is most convenient to use both. You use the first (VM
> package private classes) when you need to have a tight coupling between
> the helper/vm class and the public implementation class. You use the
> second if you only need a helper class that doesn't need tight coupling
> with the public implementation class.

The VM will always have representation dependencies on a small portion of 
the class library.  I think that most of us would agree that keeping the
the number of these classes to a minimum benefits all VM implementers. 

Given that we need these classes the challenge becomes:

 #1) Giving VM implementers the ability to modify class shape and 
    customize individual methods without copying a ton of boilerplate 
    Java code around. 

 #2) While minimizing runtime cost and complexity. 

Split-class (ClassX & VMClassX) or customized-class solutions (Tim E's 
Kernel classes) are different approaches to solving the same problem. 
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.

Also, if you ever need to change class shape (e.g. add an extra long 
field to point at a C structure) you're basically forced into the 
customized-class solution.  Why not stick to one technique?

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

Graeme Johnson
J9 VM Team, IBM Canada.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message