Hi Tim, Thanks for your thoughtful comments on the architecture of VM accessors.
> Ellison, Tim wrote: >> >> 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)? We could look at them as a VM access toolkit( beyond access provided by the Java public api ). The requirement may be broader than Classlibraries. One can eg., think of JVMTI agents inserting byte code instrumentation that uses accessors to reach the VM. > 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. > 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. Yes, accessors for functional requirements would easier to standardize on than those for optimization. However, is it worthwhile to define an initial set that can be candidates for standardization? eg., Object Accessor( get/set of fields, method invocation, create instance, serialization support, monitor enter/exit etc. ) Array Accessor( locking, get/set elements bypassing bounds check, etc. ) String Accessor( to support creation, of string objects from native buffers, string access, comparison ) ThreadStack Accessor( to access call stack trace ) Memory Accessor( to support low level operations for memory allocation/deallocation/access ) Etc. A Harmony compliant VM would then expose, at a minimum, this core set of accessor classes with a default implementation of these accessors using JNI, but compliant VM's could choose to provide more optimized implementations also. >> 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). > 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. While optimization of the public api does benefit all Java code, it may not be realistic to hold privileged VM access code to the same standard as application code. The public api has broader architectural targets which require artifacts like standard call frames, access security checks on each invocation, etc. These might become unnecessary if we intend to limit the access to these classes to non-public code only. > Using VMAccessors will be predicated on a more robust security story and > a fast Java<->VM interface. I absolutely agree. Thanks, Rana Dasgupta Intel Managed Runtime Development
