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
