incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: Do we need to change the scope of the API design?
Date Thu, 03 Dec 2009 14:04:16 GMT
     Comments sprinkled throughout...

Steve Poole wrote:
> On Wed, Dec 2, 2009 at 11:53 AM, Stuart Monteith<>  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 can't really make a judgement on how realistic this approach is. 
Essentially what we are saying is we are
missing some JVM funtionality that would allow us to implement this 
feature in our RI. Thing is, if this was
accepted into the umbrella JSR, would the RI even be the implementation 
for HotSpot? Given the existing
ServiceAbility functionality, HotSpot would do well to use that instead 
of the RI. Under such circumstances
I wouldn't expect that the additional JVMTI (or elsewhere) functionality 
would be required, unless a separate
case could be made.

>> 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.
I think we ought to list what we think this functionality would be.

This is what I think the RI could do without modification to the JVM:

1. Retrieve the native thread IDs
2. Get system information - creation time, system type, processor type.
3. Get the ImageSymbols. Although without native memory, there might be 
little point in doing so.
4. Maybe Native thread ID's, registers and perhaps stacks could be 
retrieved by using GDB/MI.
5. Native libraries - ImageModule - could be reported. At a minimum 
/proc can tell us.
6. Environment variables - as the environment is reported by the JVM itself.
7. Retrieve bytecode and constant pool information

Here is what I don't think we would ever do:

1. Native memory - otherwise, we'd just work on core files.
2. Get the signal that caused the dump (RI could never do this)

With the assistance of new JVMTI features we could return:

1. The native thread ID corresponding with a JavaThread.
2. Perhaps native thread registers and stacks with help from the JVM.
3. ?
4. I think that's it.

The biggest limiter will be the circumstances under which the RI could 
be launched. i.e. there will be no crash diagnosis.
> 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

So we could return:
     public class JavaClassRIImpl implements JavaClass

for the RI but:

     public class JavaClassCoreImpl implements JavaClass, NativeAccess

for a core file implementation that would allow us to get an address in 
memory for the class.
The RI would just return the result of getID() which would effectively 
be the record ID in the file.

That seems a reasonable way of implementing it.

It has the advantage that if a JavaClass or whatever is created but 
doesn't actually exist in the JVM,
we can implement it without a "NativeAccess", which is a nicer way of 
going about thing.

As this point reiterates:
> 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
Applications could then compile against the purely implementation 
agnostic classes. Other applications that
do analysis of the native side could be written, but with a greater 
degree of care.
> 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
I think Konstantin will have lots to say, but all I would comment on is 
how we think this might be used.
I see JavaMethods being used for the following:

o For identifying methods and their names in JavaLocation
o Perhaps for retrieving bytecodes for the recreation of .class files 
(or generated/transformed classes)
o For retrieving compiled code for JIT diagnosis.

Are there others?

> 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

Stuart Monteith

View raw message