JDK-4096069 : (jni) Calling from C to Java is very slow.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.1.5,1.3.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.5.1
  • CPU: generic
  • Submitted: 1997-12-01
  • Updated: 2013-11-01
  • Resolved: 2002-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
Calling from C to Java is very slow.  In the worst case, when no
method block is provided, the calling sequence can (I think) acquire and
release as many as 8+ locks, even if the called method is not even
synchronized.  This should also have an impact on salability.

----------------------------------------------------

There seems to be some question how often this acutally happens, so I asked around and found that JavaMedia does this a lot.  Here is one comment:

----------
java sound uses callbacks from native code to java pretty
aggressively.  it calls back as often as once ever 11 
milliseconds for each audio stream being rendered.  (we
also have a few much less frequently made callbacks to 
signal that audio playback has started or finished, etc.)
since jmf uses java sound for its audio support, this will
affect the performance of jmf as well as java sound on its
own.
--------------

We also found that non-sound related parts of JMF do this often.
steve.wilson@eng 1999-01-08

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper
14-06-2004

PUBLIC COMMENTS Performance improvements will be implemented in the 1.4.1 release. Our tests show that for virtual calls, we can improve the time by 2-3 times on the second invocation. Static calls will be improved by about 35%.
10-06-2004

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
03-12-2001