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 Wed, 02 Dec 2009 06:16:41 GMT
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
 

>-----Original Message-----
>From: Steve Poole [mailto:spoole167@googlemail.com]
>Sent: Wednesday, November 25, 2009 7:44 PM
>To: kato-spec@incubator.apache.org
>Subject: Do we need to change the scope of the API design?
>
>Stuart's note on diagnosing JNI problems (thanks for the review Stuart) has
>touched on a key point  concerning what we want to do and what we can do.
>
>I think its time we discuss where we are and what happens next.
>
>Our desire to specify an API that helps people solve problems has to be
>tempered with  practical implementation considerations.   The API design
>that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
>course),  but for us to develop a matching reference implementation we know
>now that we need to get much more information from the Sun JVM than we have
>today.  Developing a full solution to match the API as it stands today is
>difficult for the Kato project as the code we would need to access is in
>OpenJDK and is under the GPL.
>
>Practically, we have few choices.  We could
>
>1 - Get a JVM Vendor to produce , or commit to produce  an implementation
>that fully covers the Image API side.
>2 - Remove all the Image API side from the design
>3 - Find a halfway point where some of the Image API stays and is optional.
>
>I've had many conversations with people concerning option 1 and the
>response
>is generally that its too expensive for the potential return.  Both for
>implementation and ongoing maintenance.
>
>Option 2 seems very draconian -  the ability to get at some of the native
>information (such as the native thread for a Java thread) just seems too
>useful to remove.
>
>I'd opt for us moving the API design towards option 3 - there are some
>basic
>changes we could do such as extracting the native access methods into a
>separate interface and allowing the implementer the choice to use it.
>
>We still need to get access to more data from the JVM (and perhaps in
>better
>ways) than we have today.  We need to get this data in such a manner as not
>to require accessing GPL code and in a way that is cheap to maintain as the
>JVM evolves.
>
>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)
>
>Comments?
>
>
>--
>Steve

Mime
View raw message