United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4655125 : adding method caching in JNIid (4096069) causes bug in invoke, HotSwap, invoke

Details
Type:
Bug
Submit Date:
2002-03-19
Status:
Resolved
Updated Date:
2002-11-13
Project Name:
JDK
Resolved Date:
2002-11-13
Component:
vm-legacy
OS:
solaris_7,generic
Sub-Component:
jvmdi
CPU:
sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0,1.4.1
Fixed Versions:
1.4.2 (mantis)

Related Reports
Relates:

Sub Tasks

Description
To optimize JNI invokes (by caching resolves), three fields:

  jint               _resolved_lock;     // Lock for updating _resolved fields
  volatile methodOop _resolved_method;   // Non NULL if method is resolved
  volatile klassOop  _resolved_receiver; // Receiver at time of resolve

and five methods:

  inline void JNIid::lock();
  inline void JNIid::unlock() ;
  methodOop resolved_method() const;
  klassOop  resolved_receiver() const;
  void set_resolved_method( methodOop m, klassOop r );

have been added to JNIid.  However, HotSwaping can make the cache incorrect,
causing the following bug: a method is invoked via JNI, the resolved method 
is cached in the JNIid, the method is replaced using HotSwap, the method 
is invoked again and because of the cache, the old method is called.  

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis


                                     
2004-06-14
PUBLIC COMMENTS

To optimize JNI invokes (by caching resolves), three fields:

  jint               _resolved_lock;     // Lock for updating _resolved fields
  volatile methodOop _resolved_method;   // Non NULL if method is resolved
  volatile klassOop  _resolved_receiver; // Receiver at time of resolve

and five methods:

  inline void JNIid::lock();
  inline void JNIid::unlock() ;
  methodOop resolved_method() const;
  klassOop  resolved_receiver() const;
  void set_resolved_method( methodOop m, klassOop r );

have been added to JNIid.  However, HotSwaping can make the cache incorrect,
causing the following bug: a method is invoked via JNI, the resolved method 
is cached in the JNIid, the method is replaced using HotSwap, the method 
is invoked again and because of the cache, the old method is called.  
                                     
2004-06-10
EVALUATION

###@###.### 2002-10-23

The HotSwapp code doesn't know about the JNIid cache and vice versa.
Looks like HotSwap should flush the cached information for each old
method.
                                     
2002-10-23
SUGGESTED FIX

Begin - ###@###.### 2002-03-19
The HotSwapping code needs, now, to invalidate the cache for
each replaced method.

This optimization (4096069) is a time/space trade-off (favoring
time over space).  It seems it is being put to only limited use.
The fields (_resolved_method, etc) could be initialized with 
the base method, since this information is known at the time
of JNIid creation.  Since this is, by far, the most common case
this will speed up invoke.  But could be used to significantly
speed up JVMDI.
End - ###@###.### 2002-03-19

###@###.### 2002-10-24

See attached 4655125-webrev.tar file for the proposed fix (pre-code review).
                                     
2002-03-19



Hardware and Software, Engineered to Work Together