I thought moxie already had an implementation of fast native calls ?
Perhaps you could look at that ?
cheers,
Robin
Mikhail Fursov wrote:
On 10/23/06, Pavel Afremov [EMAIL PROTECTED] wrote:
Mikhail could you summarize all issues which should be clarified and
possible solutions for these
On 10/23/06, Pavel Afremov [EMAIL PROTECTED] wrote:
Mikhail could you summarize all issues which should be clarified and
possible solutions for these issues?
Ok, I'm going to summarize our discussion. Correct me if I missed something.
Problem 1A: How JIT will know if a Java method must be
Hi.
On First question I think that alternative 1 is better. It's allow to avoid
creating of special or magic registration subsystem which should
provide addresses for magic native call.
On the Second question I agree with Pavel P. Null should be OK.
On Third question, I think no
Pavel,
I've found only one problem in your design.
Why do we need 1) if every component must have 2)
E.g. why not to implement get_address(int) method in C language too? AFAIU
Pavel Afremov's design has no C-interface methods at all.
--
Mikhail Fursov
Yes, this thread is not about JNI. I'll start another thread related to JNI
calls from VM components.
BTW here is another solution how to find an address of the direct native
method.
May be it's not the best, but it does not requires any calls from JIT during
the compilation (neither Java nor VM
My alternative follows:
1) Each component which exports magics, provides JAR file with class
implementing these magics. Class name is described in (e.g.) Main-Class
attribute of JAR's manifest.
2) The class contains java fast path for helper, and a pair of native
methods: one for fast-slow path,
Pavel Pervov :
My alternative follows:
1) Each component which exports magics, provides JAR file with class
implementing these magics. Class name is described in (e.g.) Main-Class
attribute of JAR's manifest.
2) The class contains java fast path for helper, and a pair of native
methods: one for
Prerequisite: each component carries its own helpers (which means no
allocation helper in VM Core, for example).
Yes, simple JIT will call helper as regular JNI method.
I missed several issues in my original message.
First: how to get address of helper?
Answer:
Two choices:
1) each component
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Sounds reasonable. And this solution joins mine and Pavel's proposals:
JIT
calls a VM method to resolve native address for direct call. JIT does
not
I would also add that we can not use any Java-based resolution schemes
at all.
(Here I
On Thursday 19 October 2006 09:21 Alex Astapchuk wrote:
Mikhail Fursov wrote:
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Pavel,
One more note.
b) About call of java method during compilation time. Jit now make
class loading during compilation.
It means that Jit
Gregory,
Gregory Shimansky:
On Thursday 19 October 2006 09:21 Alex Astapchuk wrote:
Mikhail Fursov wrote:
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Pavel,
One more note.
b) About call of java method during compilation time. Jit now make
class loading during compilation.
It
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
On 10/18/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Pavel's looks like more flexible, but I have a question with the
special interface approach: is it possible that sometimes we want to
call a library native method in fast way? If possible, shall we
require all library classes that have the
Mikhail, I think our opinions are pretty close about this topic now.
Thanks,
xiaofeng
On 10/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/18/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Pavel's looks like more flexible, but I have a question with the
special interface approach: is it
It's better to use standard JNI call, to call libraries from the side. It's
provide creation of m2n and other required stuff. The other case if the
library is ours and we know that there are methods which can be called via
fast way. In this case we can do following
For example there is
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
On 10/18/06, Pavel Afremov [EMAIL PROTECTED] wrote:
c) Use of special interface is right for security issues. It's not clear
for
me how provide security in Mikhail scheme.
It's simple :). Allow direct native calls only from classes loaded by
bootstrap classloader.
--
Mikhail Fursov
On 10/18/06, Pavel Afremov [EMAIL PROTECTED] wrote:
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
On 10/17/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/18/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Pavel's looks like more flexible, but I have a question with the
special interface approach: is it possible that sometimes we want to
call a library native method in fast way? If
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
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
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
Mikhail Fursov wrote:
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
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
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
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
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
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 [EMAIL PROTECTED] wrote:
Mikhail proposal is OK. But I think that following solution is better
1)
Hi, I think Pavel and Mikhail's proposals are essentially the same.
Pavel's looks like more flexible, but I have a question with the
special interface approach: is it possible that sometimes we want to
call a library native method in fast way? If possible, shall we
require all library classes
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
28 matches
Mail list logo
