United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4096069 : (jni) Calling from C to Java is very slow.

Details
Type:
Enhancement
Submit Date:
1997-12-01
Status:
Closed
Updated Date:
2013-11-01
Project Name:
JDK
Resolved Date:
2002-05-03
Component:
hotspot
OS:
solaris_2.5.1,generic
Sub-Component:
runtime
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.1.5,1.3.1
Fixed Versions:
1.4.1 (hopper)

Related Reports
Relates:
Relates:
Relates:

Sub Tasks

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


                                     
2004-06-14
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%.

                                     
2004-06-10
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
                                     
2001-12-03



Hardware and Software, Engineered to Work Together