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

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? 

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 ?

 

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

 

Thanks,

 

Rana Dasgupta

Intel Managed Runtime Development

 

 

Reply via email to