harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Wed, 18 Oct 2006 08:20:35 GMT
Mikhail, I think our opinions are pretty close about this topic now.


On 10/18/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 10/18/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > Pavel's looks like more flexible, but I have a question with the
> > special interface approach: is it possible that sometimes we want to
> > call a library native method in fast way? If possible, shall we
> > require all library classes that have the native method implement the
> > special interface?
> The solution if my proposal is accepted: to call any native method from a
> native library user must
> 1) Create a "header"-like Java file with a static method stub and describe
> its parameters
> 2) Add the "Java header" to the protected by VM classes (e.g. load it with
> bootstrap classloader)
> 3) Create a library that will be loaded by component manager and will
> resolve the method by (void* getAddress(name)) request.
> I think this is reasonable amount of actions to add unsafe functionality
> into VM.
> Or, is it possible for the VM developer to override a library native
> > method with a fast internal replacement that still keeps the
> > semantics? In this situation, this method is not really implemented in
> > the library class. Where will JIT find it?
> In my proposal: Yes.  A component (VM,GC) can return an address not only
> for  'persistent' functions but of  generated ones (like helpers we have
> today)
> And we probably don't want over-generality to the design of fast
> > native method invocation. We'd better keep them internally to the VM
> > at the moment until we see real need to open this contract interface
> > to external library/application developers. So if you agree with this,
> > the set of non-JNI native methods for JIT to handle are very limited
> > -- they are actually just some JVM internal functions (plus some
> > special cases for speedup). We probably want them more closed than
> > open just like the inlined helpers.
> Completely agree. This functionality must be invisible for usual Java
> developers. Before we realize we need it we must hide the functionality from
> classlib developers too.
> --
> Mikhail Fursov

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message