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 native method implement the special interface?
The solution if my proposal is accepted: to call any native method from a native library user must 1) Create a "header"-like Java file with a static method stub and describe its parameters 2) Add the "Java header" to the protected by VM classes (e.g. load it with bootstrap classloader) 3) Create a library that will be loaded by component manager and will resolve the method by (void* getAddress(name)) request. I think this is reasonable amount of actions to add unsafe functionality into VM. Or, is it possible for the VM developer to override a library native
method with a fast internal replacement that still keeps the semantics? In this situation, this method is not really implemented in the library class. Where will JIT find it?
In my proposal: Yes. A component (VM,GC) can return an address not only for 'persistent' functions but of generated ones (like helpers we have today) And we probably don't want over-generality to the design of fast
native method invocation. We'd better keep them internally to the VM at the moment until we see real need to open this contract interface to external library/application developers. So if you agree with this, the set of non-JNI native methods for JIT to handle are very limited -- they are actually just some JVM internal functions (plus some special cases for speedup). We probably want them more closed than open just like the inlined helpers.
Completely agree. This functionality must be invisible for usual Java developers. Before we realize we need it we must hide the functionality from classlib developers too. -- Mikhail Fursov
