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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
