|
Quick Lists
|
|
Bug ID:
|
4655125
|
|
Votes
|
1
|
|
Synopsis
|
adding method caching in JNIid (4096069) causes bug in invoke, HotSwap, invoke
|
|
Category
|
hotspot:jvmdi
|
|
Reported Against
|
1.4
, hopper
|
|
Release Fixed
|
1.4.2(mantis)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
4096069
|
|
Submit Date
|
19-MAR-2002
|
|
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.
|
|
Work Around
|
N/A
|
|
Evaluation
|
xxxxx@xxxxx 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.
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |