Bug ID: JDK-6393258 crash: redefine classes method order change incomplete

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	JDK 6
5.0u8Fixed	6 b79Fixed

This bug affects the following JTREG test:

    java/lang/instrument/IsModifiableClassAgent.java

When the new class file being processed by a redefine has a different method order than the original (even though the methods are sorted by method name at load time the order may still be different because of overloading) redefine needs to adjust the method orders to match-up (see 6328000).

However, the implementation of 6328000 is incomplete.  The order of the methods is changed, but the corollary changes are not done.  Each of the following need to be adjusted: 

  1. Methods know their index
  2. Method annotations are stored in parallel arrays in the class
  3. The EnclosingMethod annotation holds a method index
  4. vtable/itable order may be OK, but should be checked

because of the first, the java.lang.instrument test IsModifiableClassAgent.java is crashing.

Here is an example of the failing assert:

IsModifiableClassAgent started
modifiable: 315. unmodifiable: 45
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/jniId.cpp:862]
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/net/prt-solsparc-q1-10/tmp/PrtBuildDir/workspace/src/share/vm/prims/jniId.cpp, 862 [ Patched ]), pid=4346, tid=4
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20060305005443.ss45998.hs_jref-debug mixed mode)
#
# Error: assert(jniIdSupport::checked_to_method_oop(jmid)->method_index() == method()->method_index(),"method indices don't match")
# An error report file with more information is saved as hs_err_pid4346.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
The previous entry mentions:

  4. vtable/itable order may be OK, but should be checked

so this entry will document the checking. Method entry normalization
is done in VM_RedefineClasses::compare_and_normalize_class_versions()
which is called from VM_RedefineClasses::load_new_class_versions()
which is called by the VM Operation's doit_prologue() function.

The v/i-tables are initialized in VM_RedefineClasses::redefine_single_class()
which is called by the VM Operation's doit() function. So v/i-table
initialization takes place after method entries have been normalized
so there is no work to do for item #4.

SUGGESTED FIX See attached 6393258-webrev-cr0.tgz file for the complete proposed fix.
23-03-2006
EVALUATION Here are the four items that Robert identified: 1. Methods know their index This one is covered by the set_method_index() calls that Robert included in the original suggested fix. 2. Method annotations are stored in parallel arrays in the class The methods_annotations(), methods_parameter_annotations(), and methods_default_annotations() fields need to be swapped if the corresponding method has been swapped. 3. The EnclosingMethod annotation holds a method index From my investigation, this method index is a Constant Pool index and not an index into the methods array. I don't believe any swapping is required for that annotation. 4. vtable/itable order may be OK, but should be checked No more work needed for this one.
21-03-2006
SUGGESTED FIX The fix for 6328000 was backported to 1.5.0_08-B01. When this fix is finished it will also need to be backported.
02-03-2006
SUGGESTED FIX The following fix to jvmtiRedefineClasses.cpp corrects the crash in IsModifiableClassAgent.java -- if (k_method->signature() == m->signature()) { // found a match so swap the methods k_new_methods->obj_at_put(i, m); + m->set_method_index(i); k_new_methods->obj_at_put(j, k_new_method); + k_new_method->set_method_index(j); k_new_method = m; break; } But it does not correct the other problems, and if reorder_based_on_method_index in methodOop.cpp or a related mechanism is used, this approach would defeat it.
02-03-2006
EVALUATION This may impact users of redefine classes, but is certain to impact users of retransform classes because of changes in method order by the reconstituter. It is thus critical to fix.
02-03-2006

Relates :	JDK-5002251 - potential bug with annotations and class file evolution
Relates :	JDK-6272221 - assertion failure in ContiguousSpace::block_size after massive number of RedefineClasses
Relates :	JDK-6328000 - class redefinition failed "method deleted"