harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Tue, 17 Oct 2006 17:14:38 GMT
   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.


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

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