incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <konstantin.s.bobrov...@intel.com>
Subject RE: Do we need to change the scope of the API design?
Date Thu, 03 Dec 2009 12:44:14 GMT
Steve,

See my comments in-lined.

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
 

>-----Original Message-----
>From: Steve Poole [mailto:spoole167@googlemail.com]
>Sent: Wednesday, December 02, 2009 7:40 PM
>To: kato-spec@incubator.apache.org
>Subject: Re: Do we need to change the scope of the API design?
>
>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
>

[Bobrovsky, Konstantin S] 
I don't quite understand the intent here. Will this separate interface be extended by other
KATO API elements?


>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
>

[Bobrovsky, Konstantin S] Is this to avoid "empty" implementations in the API? E.g. client
must check is 'obj instanceof NativeAccess' before querying id/address, and initial RI will
have most objects not implementing the NativeAccess interface. - ? 

>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();

[Bobrovsky, Konstantin S] 
What it will return? Only method's bytecode? We should be able to access the rest of the classfile
data (constant pool) - this can belong to JavaClass.

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

[Bobrovsky, Konstantin S] 
As I said earlier, I strongly believe that there should be an individual interface for representing
method's code. I'll write more on this in a separate topic.

>
>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
View raw message