United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7017732 move static fields into Class to prepare for perm gen removal
JDK-7017732 : move static fields into Class to prepare for perm gen removal

Details
Type:
Bug
Submit Date:
2011-02-07
Status:
Closed
Updated Date:
2013-06-20
Project Name:
JDK
Resolved Date:
2011-04-24
Component:
hotspot
OS:
solaris_2.5.1,generic,solaris_10
Sub-Component:
runtime
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs21,1.4.1
Fixed Versions:
hs21 (b06)

Related Reports
Backport:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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-gc/hotspot/rev/c7f3d0b4570f
                                     
2011-03-19
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7f3d0b4570f
                                     
2011-03-25
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c7f3d0b4570f
                                     
2011-03-25
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c7f3d0b4570f
                                     
2011-03-25
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.
                                     
2011-03-22



Hardware and Software, Engineered to Work Together