JDK-7017732 : move static fields into Class to prepare for perm gen removal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs21,1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.5.1,solaris_10
  • CPU: generic,x86
  • Submitted: 2011-02-07
  • Updated: 2013-06-20
  • Resolved: 2011-04-24
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 Other
7Fixed hs21Fixed
Related Reports
Duplicate :  
JDK-7024561 - JSR 292 constant pool cache _f1 field doesn't get properly updated with parallel GC
Relates :  
JDK-7031614 - jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue
Relates :  
JDK-7093328 - JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives
Relates :  
JDK-7028374 - race in fix_oop_relocations for scavengeable nmethods
Relates :  
JDK-7032306 - Fastdebug build failure on Solaris with SS11 compilers
Relates :  
JDK-7098528 - crash with java -XX:+ExtendedDTraceProbes
Description
Currently static fields are stored in the instanceKlass but when those are moved into native memory we'd have to have a new card mark strategy for static fields.  This could be something like setting a flag in the instanceKlass and then rescanning every klass during a GC which seems expensive or marking the card for the java.lang.Class then making sure to scan the instanceKlass when scanning the Class.  If we move them into the Class then almost all the existing machinery works exactly as it always has.  The only execution difference is which constant is materialized for the field access.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7f3d0b4570f
25-03-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c7f3d0b4570f
25-03-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7f3d0b4570f
25-03-2011
EVALUATION 7017732: move static fields into Class to prepare for perm gen removal Reviewed-by: kvn, coleenp, twisti, stefank Currently static fields are stored in the instanceKlass but when those are moved into native memory we'd have to have a new card mark strategy for static fields. This could be something like setting a flag in the instanceKlass and then rescanning every klass during a GC which seems expensive or marking the card for the java.lang.Class then making sure to scan the instanceKlass when scanning the Class. If we move them into the Class then almost all the existing machinery works exactly as it always has. The only execution difference is which constant is materialized for the field access. Most of the machinery for static fields is now over in javaClasses.cpp. The bootstrap had to change slightly since we don't have Class until we've loaded a few classes but it all fits into the existing mirror creation logic. I also only create mirrors for real Java classes whereas previously we also created them for internal klasses we create. The main implementation oddity is that java.lang.Class instances are now variably sized. This required a small change in size_given_klass and a new instanceMirrorKlass to handle visiting the oops in them. Performance is unchanged. Tested with ctw, runthese, nsk jvmti tests and jbb with the various collectors.
22-03-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c7f3d0b4570f
19-03-2011