Pavel,
Though the proposal look interesting, but some things are not clear.
Could you please shed a bit of light on it?
> 1) The special interface MagicNativeCall should be created. The
> interface has only one method CallAddress getCallAddress(String
> methodName)..
An interface method implies an instance of some class.
> 2) If JIT find call of native method, it tries to find call address
> using getCallAddress method.
Are we still talking about *compilation* time?
The JIT must know how to call the method *at the compile time*, long
before the code is executed.
What instance should the JIT use - again, at the compile time? And how?
We can not use a lazy resolution scheme here, for both the performance
and implemetation reasons: think about inlining of
'load_interface_vtable' helper.
If its fast path fails, then it goes to the slow path.
On the slow path the code must lazily resolve the slow path helper
address, and to do this, it should call... surprise! surprise!
load_interface_vtable helper.
"Recursion - see recursion" :-)
I don't see how the *runtime* things like interface/virtual methods may
help at the *compile* time.
I was thinking about something *really* static, what is known at the
compile time, before the execution.
Something like 'implements' or 'trows' clauses. Or annotations.
--
Thanks,
Alex
Pavel Afremov 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
