incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Do we need to change the scope of the API design?
Date Wed, 02 Dec 2009 13:40:25 GMT
On Wed, Dec 2, 2009 at 11:53 AM, Stuart Monteith <stukato@stoo.me.uk> wrote:

> Hello,
>    I agree Konstantin, technically any changes are going to be challenging,
> actually
> having changes accepted will probably be even more difficult. As this is
> not a Sun led project,
> JSR-326 couldn't make changes to the HotSpot JVM in the same way as JSR-163
> (JVM TI).
>
> As a JSR we can propose them but they would not be accepted unless Jsr 326
made it into an Umbrella JSR.
we would also have to consider how much a gap it would be to have a RI
without the capability provided by these proposals.


> I think we need to understand what extensions for JVMTI we are talking
> about, I don't believe
> they have been written down. Perhaps if they were small and uncontroversial
> the odds would be
> better.
>
> I said JVMTI just as a way to get people thinking about the idea of a 'c'
level interface.  I also had in my head that the sort of data we needed was
going to be process level type stuff and a 'c' api made it easier to get at.


My proposal is something like this

1 -  The following methods signatures would be abstracted out into a
separate interface  (which I'll call NativeAccess to be contentious) :

 List<ImageSection> getSections();


ImagePointer getAddress() throws CorruptDataException;

(there are other methods of a similar intent which would be renamed to one
of these)

The method signature

 ImagePointer getID()

would change to return either a primitive or a some new opaque handle object

2 -  A particular implementation  of the API would be at liberty to  return
objects which implemented this new Interface - but is not forced to do so

3 -  That would leave us with

3A : JavaThread  has two remaining methods for accessing native data :

  ImagePointer getJNIEnv() throws CorruptDataException;
 ImageThread getImageThread() throws CorruptDataException, DataUnavailable;

I would be inclined to replace getJNIEnv and getImageThread on JavaThread
with a single getNativeThread which returned an object from which you could
do getJNIEnv etc It would probably be something called  like
NativeJavaThread and could (but is not required to) implement ImageThread

3b:  JavaMethod has :

  List<ImageSection> getBytecodeSections();
  List<ImageSection> getCompiledSections();

I would propose that for  JavaMethod we converted  List<ImageSection>
getBytecodeSections();  into byte[]  getByteCode();

We also rename getCompiledSections() into getSections() so that it could be
abstracted out into the NativeAccess interface


3C: JavaRuntime has :

JavaObject getObjectAtAddress(ImagePointer address) throws
CorruptDataException, IllegalArgumentException, MemoryAccessException,
DataUnavailable;

This get converted so the ImagePointer passed in becomes the same primitive
or new opaque type as we define for getID()


Summary:  The abstraction and small changes decouples the process level
stuff from the JavaRuntime.  Those implementations who want to provide the
data can do so but those who do not are not disadvantaged.

That still leaves us with the desire to get at more of the native
information which I think is mostly what I've listed above :

A) Access to some  native thread information
B) Access to the JNIEnv of a JavaThread
C) Bytecode loaded for a particular method

I'll stop there and see what you all think...



Regards,
   Stuart

Bobrovsky, Konstantin S wrote:

> Steve,
>>
>> I found I did not answer this proposal
>>
>>
>>
>>> My idea for resolving this conundrum is to propose that we include in our
>>> API design either a new JVM 'C' API or  extensions to JVMTI. We would not
>>> implement these additions in the RI but would rely on others to provide
>>> an
>>> implementation.  (We would design the RI and the API to make this extra
>>> information optional)
>>>
>>>
>> I'm a little skeptical about new C API or even JVMTI extensions. Sun put
>> lots of efforts in developing JVMPI/JVMTI, endless list of bugs has been
>> fixed - not only in JVMTI-specific code, but in other JVM and JIT parts
>> which had to be changed to support certain JVMTI functionality (such as
>> method entry/exit events, EarlyReturn support).
>>
>> There is a risk of this new API to require lots of efforts to develop and
>> debug a proof-of-concept prototype (RI is possibly only for Harmony, I
>> guess).
>>
>> Thanks,
>> Konst
>>
>> Intel Novosibirsk
>> Closed Joint Stock Company Intel A/O
>> Registered legal address: Krylatsky Hills Business Park,
>> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
>> Russian Federation
>>
>>
>>
>
> --
> Stuart Monteith
> http://blog.stoo.me.uk/
>
>


-- 
Steve

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