Bug ID: JDK-4655125 adding method caching in JNIid (4096069) causes bug in invoke, HotSwap, invoke

Versions (Unresolved/Resolved/Fixed)

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.2 mantisFixed

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.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004
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.
10-06-2004
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.
23-10-2002
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).
19-03-2002