JDK-6939207 : refactor constant pool index processing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-03-30
  • Updated: 2010-09-24
  • Resolved: 2010-06-26
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.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Relates :  
JDK-6939203 - JSR 292 needs method handle constants
Relates :  
JDK-6981788 - GC map generator sometimes picks up the wrong kind of instruction operand
Relates :  
JDK-6957004 - MethodComparator uses the wrong CP index accessor
Description
Bug 6939203 (JSR 292 needs method handle constants) requires an extension to the construct pool structure and the ldc bytecode.  In particular, it needs to use the CP cache to manage method references, and therefore the ldc bytecode (when used by the new functionality) need to refer to a CP cache index.

To do this safely, the JVM's bytecode parsing modules must make a more rigorous distinction between types of bytecode indexes.  This change makes clear the difference between (a) a CP index and (b) a CP cache index, and also (1) a network-byte-order index and (2) a native-byte-order index.  With clarified distinctions, enforced mechanically, we can safely make the needed modifications.

For a draft of this change, see:
  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/5353e955d315/cpindex-cleanup.patch
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ab102d5d923e
23-05-2010