incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Do we need to change the scope of the API design?
Date Wed, 02 Dec 2009 11:53:49 GMT
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).

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.


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/


Mime
View raw message