JDK-6394084 : Redefine class can't handle addition of 64 bit constants in JDK1.5.0_04
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0u4
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2006-03-05
  • Updated: 2012-02-01
  • Resolved: 2006-04-04
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
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)


FULL OS VERSION :
Linux Fedora Core 3 kernel 2.6.12-1.1372_FC3


A DESCRIPTION OF THE PROBLEM :
Adding a double or long constant to a class and forcing a redefiniton of it through JDI redefineClasses picks up a seeming random value of the constant.
The correct behaviour is seen for 32 bit constants. JRE1.5.0-b64 does not exhibit this bug.

This makes it difficult to rely on class redefinition for fast prototyping.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the source code under JDK 1.5.0 and execute it using JRE 1.5.0_05

Then change the line System.out.println(a); to System.out.println(a*2L); or (a*2.0); and force a class redefinion through JDI


EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: 1000 should be printed once per second
Actual:
1000
1000
1000
1000
==JDIHarness: agen.bin.Test will be replaced
==JDIHarness: Suspending JVM
==JDIHarness: Uploading 1 classes
==JDIHarness: Resuming JVM
-6624593188399085616
-6624593188399085616
[the number printed following redefiniton appears random, and subsequent redefinitions change this number and sometimes get it correct]
REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Test {
    public static void main(String argv[]) throws InterruptedException {
	while (true) {
	    doStuff(1000);
	    Thread.sleep(1000);
	}
    }
    private static void doStuff(int a) {
	System.out.println(a);
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Revert to JRE1.5.0 or (possibly) perform the redefinition twice.

Comments
SUGGESTED FIX See 6272221 for the webrev for the proposed fix.
23-03-2006

EVALUATION It turns out that constant pool merging for JVM_CONSTANT_Double and JVM_CONSTANT_Long entries works mostly by accident. JVM_CONSTANT_Double and JVM_CONSTANT_Long entries occupy two constant pool entries and all other constant pool entry types occupy one constant pool entry. If a JVM_CONSTANT_Double or JVM_CONSTANT_Long is the last entry appended to a constant pool during the merging process, then the last four bytes of the double or long value go right off the end and clobber the constantPoolOopDesc._tags field. If that doesn't crash GC, then when the _tags field is updated by GC, then the long or double value will change.
23-03-2006