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: [arch] VM/Classlibrary Interface ( VM Accessors )
Date Mon, 05 Sep 2005 10:39:29 GMT
Hi Rana,

Dasgupta, Rana wrote:
> I would like to invite discussion and comments from the community on the
> VM Accessor component in the Harmony Modular JVM diagram, on its
> functionality, design and implementation. Here are some initial
> thoughts. 
> 
>  
> 
> These are a helper set of singleton Java classes to support Classlibrary
> implementation. We can instantiate them through an Accessor factory
> interface ( Modular JVM diagram ). They will provide access to VM
> functionality not exposed through the public Java api.

So this is a "classlibrary developer's toolkit" ?  I assume the goal is
to allow implementation of classlibrary functionality in pure Java that
currently has to be written using native code (assuming a C-based VM)?

> Examples would be
> object accessors( for direct get/set of object fields, object allocation
> bypassing constructors, etc. ), array accessors ( to access arrays
> bypassing bounds checks, manipulating GC on array types ), thread stack
> accessors etc. Thoughts on how we define a complete list of VM accessor
> classes? 

Your list appears to be a blend of operations that are functional
enhancements and optimization enhancements.  I expect that the
functional enhancements would be discovered by need of the library
implementors.  The optimization enhancements would likey vary by VM/JIT
implementor, with some requiring more 'hints' than others to generate
good code.

> How will we implement accessors in Harmony? An option could be using
> JNI, and distributing/packaging VM accessors with the class library, but
> there are performance problems associated with this. A proprietory
> implementation tightly coupled to the VM could expose functionality in
> the JIT or GC engine.  This could potentially perform much better( be
> inlinable by the JIT ), but how does that impact portability of the
> accessor classes? 

I would expect such functionality to be VM-specific, and therefore part
of the kernel classes provided by the VM-implementor.  The question is
how many accessors it is reasonable to expect such an implementor to be
required to support in order to run the Harmony classlibraries.

> We want to restrict access to the accessor functionality to the
> Classlibrary, etc. One way to enforce this policy would be for the
> accessor factory to check that the requesting class is on some white
> list of classes before returning an accessor reference. Thoughts on
> alternative schemes ?

The problem with this scheme is that it requires everyone to follow the
pattern.  There is a risk that somebody may forget to check the list, or
that a 'white' intermediary may pass-out a reference to someone who does
not have rights to it directly.  The componentization model discussed
earlier would allow accessors to be in a separate component (which at
least would prevent non-white code from ever referencing the accessors).

> There seems to be an opportunity for an OpenSource programming model and
> standardization of portions of the accessor api.

My initial reaction is that we should use such functionality
judiciously.  Classlibrary code should be using public APIs wherever and
whenever possible.

The VMs' and JITs' optimization of public API will benefit both the
classlibrary implementation and application code; and we don't want to
be extending the language by the back door.

Using VMAccessors will be predicated on a more robust security story and
a fast Java<->VM interface.

Regards,
Tim

> Thanks,
> 
>  
> 
> Rana Dasgupta
> 
> Intel Managed Runtime Development
> 
>  
> 
>  
> 
> 

-- 

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

Mime
View raw message