harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dasgupta, Rana" <rana.dasgu...@intel.com>
Subject RE: [arch] VM/Classlibrary Interface ( VM Accessors )
Date Mon, 12 Sep 2005 16:19:07 GMT
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

 

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message