JDK-7086585 : make Java field injection more flexible
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs22
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2011-09-02
  • Updated: 2011-10-07
  • Resolved: 2011-09-30
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 7 JDK 8 Other
7u2Fixed 8Fixed hs22Fixed
Related Reports
Relates :  
JDK-7090654 - nightly failures after 7086585
Relates :  
JDK-7088481 - JSR 292: remove the vm specific fields from the java.lang.invoke classes
Relates :  
JDK-7092278 - "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137"
Description
Classes which are special to the JVM often need fields for the VM's use.  Currently the mechanism for this is adhoc or relies on the Java code declaring the needed fields.  We need a mechanism for flexibly injecting needed fields.
Comments
EVALUATION See main CR
24-09-2011
EVALUATION 7086585: make Java field injection more flexible Reviewed-by: jrose, twisti, kvn, coleenp Classes which are special to the JVM often need fields for the VM's use. Currently the mechanism for this is adhoc or relies on the Java code declaring the needed fields. We need a mechanism for flexibly injecting needed fields. The basic idea is to built a standard mechanism for declaring injected fields and to inject them during class file parsing so that they get laid out and tracked like normal fields. This is also means that they can simply be looked up when CDS is used so we don't have to rely on hardcoding them. To do this I hide the encoding of the fields array and replaced all existing iteration with a new set of *FieldStream classes. JavaFieldStream only iterates true Java fields so the behavious of existing code is completely unchanged. The new fields use a special access flag JVM_ACC_INTERNAL to describe themselves and instead of having the name_index and signature_index refer to the constant pool they are vmSymbols::SID so they are looked up directly from the vmSymbols. All of this is hidden inside the RawFieldDescriptor class which is responsible for decoding fields from the field array. I also cleaned up the field layout code a bit. I eliminated the _ALIGNED_ AllocationType since there's no longer any difference in how we align double word types. I turned FieldAllocationCount into a real class and moved some of the layout code into it. I deleted the nonexistent MethodHandle::vmslot field. I moved ClassLoader::parallelCapable into java_lang_ClassLoader. I deleted some dead field injection like the Reference.discovered field which has existed since 1.5, and the existing logic for java.lang.Class fields since it now uses the field injection machinery. Tested with runthese, the sajdi tests, the tmtools suite, the nsk regression, jdb, jdi, jvmti, hprof and jit subsuites along with vm/mlvm, but with and without the JDK changes that remove these fields and rely on injection to introduce them. They will be removed under 7088481 and those changes are http://cr.openjdk.java.net/~never/7088481.
12-09-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e6b1331a51d2
11-09-2011