EVALUATION
The actual rfe refers to the 1.1 Classic VM implementation. Calling into the VM using JNI is faster in 1.2 and 1.3, but the performance of method invocation through JNI can still be improved. VM runtime work in this area is planned for the Merlin release.
Also, the new "unsafe" API in Merlin for accessing native data structures from Java will in many cases enable software architecture where frequent callbacks are no longer needed.
steffen.grarup@eng 2000-05-24
Unsafe API was designed to solve this kind of problems.
It dramatically speeds up Java - native interaction.
david.wallman@Eng 2001-06-15
The attachment that I just added to this bug shows that there
is still a lot of room for improvement in calling from native
code into Java code. If the target method is a virtual method,
it takes 66 times longer to call a method (which does nothing)
than to call out from Java to Native. Here is a dump from the
attached program. The times are in milliseconds.
Starting Calling Native From Java
Ending Calling Native From Java, elapsed time: 1137
Starting Calling Static Java From Native Code
Ending Calling Static Java From Native Code, elapsed time: 19267
Starting Calling Non Static Java From Native Code
Ending Calling Non Static Java From Native Code, elapsed time: 75292
The top functions in the VM contributing to the performance bottlenecks
are jni_resolve_virtual_call and SignatureIterator::parse_type used by
the jni argument pusher. It should be relatively easy to cache the
results of the resolve and keep a cache of native signatures in order
to reduce the bullk of this overhead.
###@###.### 2001-11-08
The code checked into the hopper source base improves the
performance as shown in the table below.
Sparc32 unmodified 1247 29671 65344
Sparc32 modified 1239 17510 17906
(1.69) (3.65)
Sparc64 unmodified 1824 29767 66363
Sparc64 modified 1686 21657 21053
(1.37) (3.15)
More improvement can be had if we are willing to generate platform specific
assembly language stubs. Since calling native functions are
more frequent than calling into Java from native code, I decided to not
complicate the source base and make the VM less portable/maintainable.
###@###.### 2001-12-03
|
Java