harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Tue, 17 Oct 2006 19:40:07 GMT
Mihail,
It may border on overengineering but I like Pavel's below approach.  If you
think its too hard to implement, my second choice would be your scheme.



On 10/17/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
> > >
> > >
> >
> >
>
>


-- 
Weldon Washburn
Intel Middleware Products Division
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message