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