harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Wed, 18 Oct 2006 08:46:31 GMT
It's better to use standard JNI call, to call libraries from the side. It's
provide creation of m2n and other required stuff. The other case if the
library is ours and we know that there are methods which can be called via
fast way. In this case we can do following



For example there is



class MyLibraryClass {

    int methodA();

    void methodB(int);

}



Wrapper should be added

.

Class MyFastLibraryClass extends MyLibraryClass {

    CallAddress getCallAddress(String methodName); // which returns fast
call addresses.

}



BR

Pavel Afremov


On 10/18/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> Hi, I think Pavel and Mikhail's proposals are essentially the same.
> 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?
>
> 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?
>
> 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.
>
> Thanks,
> xiaofeng
>
> On 10/18/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> > Mikhail proposal is OK. But I think that following solution is better
> >
> >
> >
> > 1)       The special interface MagicNativeCall should be created. The
> > interface has only one method CallAddress getCallAddress(String
> methodName).
> > All native methods of classes which implement this interface should be
> > called by JIT via special "magic" way.
> >
> > 2)       If JIT find call of native method, it tries to find call
> address
> > using getCallAddress method. If null is returned by the method, usual
> call
> > of JNI method should be processed. In other case magic native call can
> be
> > included instead JNI call. Result returned by getCallAddress can
> and  should
> > be cashed by JIT for performance reasons.
> >
> > 3)       I propose for the firs time use fastcall calling convention. In
> > future new additional method can be added MagicNativeCall interface. It
> can
> > be named as getCallType for example. If it returns JNI – jit should use
> > stdcall, if FastWay – fast call. Also we can add special Magic type of
> > calling convention. In this type of call one can select Register and
> stack
> > slot for every parameter and return value.
> >
> >
> >
> > It can looks like:
> >
> >
> >
> > ReturnValue methodName(InParameterList )  or
> >
> > void  methodName(InParameterList, OutParameterList).
> >
> >
> > ReturValue is an void or OutValue, InParameterList  is an empty or
> separated
> > by comma "," list of the InValue, OutParameterList is an empty or
> separated
> > by comma "," list of the OutValue.
> >
> > The OutValue can by one of OutRegisterParametr## or OutStackParametr##,
> > where ## number of register or call in the stack, which are possible on
> the
> > current platform.
> >
> >
> > The InValue can be one of InRegisterParametr## or InStackParametr##.
> >
> >
> >
> > Register## and Stack## is the short aliases for InRegisterParametr## and
> > InStackParametr## correspondently. Result is the short alias for
> > OutRegisterParametr00 (EAX on ia32).
> >
> >
> >
> > Generics can be used for type safety.
> >
> >
> >
> > Thanks.
> >
> > Pavel Afremov.
> >
> >
> > On 10/17/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > >
> > > Mikhail,
> > >   All this looks reasonable to me. At least to go ahead. Regarding 2A,
> > > could the jit cache this information for re-use?
> > > Alternatively, the JIT can do all this at startup...by going thru the
> > > contract class of fastpath java methods and querying the component
> manager
> > > for the native addresses of the slow counterparts.
> > >
> > > Thanks,
> > > Rana
> > >
> > >
> > > On 10/17/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > >
> > > > All,
> > > > Finally we have almost everything finished to post "helper's
> fast-path
> > > > inlining" framework into JIRA.
> > > >
> > > > The issue is left is how to call native slow-path versions of the
> from
> > > > Java
> > > > code. We already discussed some of the aspects, but there was no
> > > detailed
> > > > discussion with a final agreement what API we will use.
> > > >
> > > > Let's make a final decision so I can add the code into JIRA.
> > > >
> > > > I'm sending my vision of the solution. Correct me or advise another
> > > > approach.
> > > >
> > > > Step 1:  How JIT will know if a Java method must be replaced with a
> > > native
> > > > helper call.
> > > > Solution 1.A: Every Java method that must be replaced with native
> call
> > > > must
> > > > be a static method and must have special "Native" runtime method
> > > > annotation.
> > > >
> > > > Step 2: How JIT will get the address of the native method to
> generate a
> > > > direct call?
> > > > Solution 2.A: Every Java method that must be replaced with native
> call
> > > > must
> > > > have special "Component" annotation.
> > > > JIT will use this annotation to ask Component Manager to access to
> the
> > > > specified component by it's name and call "void* getAddress(const
> char*
> > > > methodName)" component's method to get the address of a helper. That
> is
> > > > every component that have native calls from Java must provide this
> > > > interface.
> > > >
> > > > Step 3: How JIT will know which calling convention to use?
> > > > Solution 3.A: Use method's annotation again.
> > > >
> > > >
> > > > These were all of the problems with native calls. Now we need to
> agree
> > > if
> > > > the solution proposed is OK or find another one.
> > > > Please note, that this is just the first implementation. We can
> extend
> > > it
> > > > with more features in the future.
> > > >
> > > >
> > > >
> > > > --
> > > > 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message