Pavel,
One more note.
> b) About call of java method during compilation time. Jit now make
class loading during compilation.
> It means that Jit make call of java method.
> So I don't think that it's the other case.
It is different.
The JIT itself does not call Java code.
All what JIT does is calling VM's resolve_{anything}. It's VM who may
execute the Java code during the resolution.
The JIT itself neither has a way to call an arbitrary Java method during
the compilation, neither has an access to JNI functionality.
--
Thanks,
Alex
Pavel Afremov ?????:
Hello.
My answers is here:
a) About resolving during compilation time
If Jit compiles call of the method from the current class, it means that
resolving has been already done, and not additional resolving is not
required to understand is class implements magic interface or not. If Jit
compiles call of the method from other class it should resolve that
class to
understand is it usual call or JNI, as I understand. So no additional work
again.
b) About call of java method during compilation time. Jit now make class
loading during compilation. It means that Jit make call of java method.
So I
don't think that it's the other case. To provide work of getCallAddress
without class initializing, additional requirements can be put forward. If
Jit will implements lazy resolution in future, compilation of the method
call and getCallAddress invoking will be put into lazy resolution stub.
c) Use of special interface is right for security issues. It's not clear
for
me how provide security in Mikhail scheme.
Thanks
Pavel Afremov.
On 10/18/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Pavel,
I completely agree with Alex critics. But the thread is to discuss and to
find the best solution that could be implemented fast.
Sorry, some questions I have are the same as Alex's.
On 10/18/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
>
> 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.
a. Object instance? Where should I get it during the compilation?
b. Why to use marker interface if we can use annotations to provide all
knowledge we need in the same way (e.g. calling convention/if
native/other
knowledge that may be needed)?
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.
a. Self-describing Java code (I mean getCallAddress()) - this is very
good.
b. Calling virtual method from the JIT during the compilation is not a
good
idea.
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.
a. The development is limited to support only basic CCs - I agree. All
other
calling convention could be discussed latter.
b. Why to use "abstract lists" but not the named and typed parameters
like
in Java?
--
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]
