JDK-8003420 : NPG: make new GC root for pd_set
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-11-14
  • Updated: 2013-10-15
  • Resolved: 2013-10-10
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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-7145569 - G1: optimize nmethods scanning
Relates :  
JDK-6490401 - Avoid unnecessary system dictionary scanning during young GCs
Relates :  
JDK-8004888 - G1: PSR large heap case shows steady increase in ART
Description
The protection_domain oops in the pd_set in the SystemDictionary are the only reason now that the system dictionary needs to be walked during young collection.   The assumption is that there aren't a lot of protection domain oops here, so they could be moved to another root so that they can be walked during GC without walking the system dictionary.

This could be a reasonable performance improvement.

Need to 1 - gather statistics about how many protection domain oops are in system dictionary to verify that this is worth doing (vs. going by my gut feeling).   Then run performance tests before and after.
Comments
If you make the effort to rebase both patches on jdk8-b99 (only add the nmethod patch and yours) we already have baseline measurements and nmethod only improvement measurements. We can ask PSR to redo exactly that run. I added a graph to JDK-7145569 which shows how much system dictionary scan grows over time.
21-08-2013
I will try to do that. Do we need to increase the run time? JDK-8004888 (G1: PSR large heap case shows steady increase in AR) ran for ~13000 seconds, and it seems that all the slow down over time is caused by Ext Root Scanning. Do you know how much of the slow down in JDK-8004888 has been fixed in JDK-8015237 (parallel scanning of interned strings).
21-08-2013
I think in these results the code root scan drowns out the improvements in the system dictionary scanning, and the full gcs prevent the system dictionary becoming too large. Is it possible to rebase the patch on the nmethod changes (JDK-7145569) and retest? They are in the hotspot-gc repository already.
21-08-2013
prototype_baseline.log prototype_patched.log These are log files for "CRM FUSE" executed by PSR Team (Stanley G) that were used to generate Monica's graphs.
21-08-2013
Comments from Monica B: I spent some time plotting all the graphs and it seems to me that Ioi's patch does provide benefits. Attached are two of the graphs that capture the essence of his change: See attached images: prototype_baseline.png - before patch Here you can see how the average ext root scanning time increases steadily up until a full GC prototype_patched.png - after patch In the test/patched version, you don't see that much of an increase. Of-course there are other changes that need to happen to get it to not increase at all. And also having full GCs is not helping.
21-08-2013
I ran Eclipse. It has 15924 systemDictionary entries (7505 of which are initiating entries), and we have 7696 ProtectionDomainEntry, with 131 unique ProtectionDomain objects. With MedRec, it loads about 20000 classes (?) and has 9708 ProtectionDomainEntry, with 372 unique ProtectionDomain objects. So it seems like using a hashtable to combine unique entries is worthwhile.
24-07-2013
Change to P3 as reduced GC pauses is important for JDK8.
17-07-2013
Great :)
15-07-2013
A *very* preliminary webrev: http://cr.openjdk.java.net/%7Eiklam/8003420/dict_pd_set_001/
15-07-2013
Sorry, I commented too quickly .... Here's an example case where you have multiple entries in the DictionaryEntry::_pd_set: * You have A.jar and B.jar in your classpath, each with a different signer * A.jar has class C1 and B.jar has class C2, both of them are direct subclasses of java.lang.Object * When C1 and C2 are resolved, a single DictionaryEntry is created: {klass=java.lang.Object, loader=sun/misc/Launcher$AppClassLoader} * This entry has two protection domains (one for A.jar and one for B.jar)
12-07-2013
Many classes share the same protection domains. In many cases there's just a single protection domain for the entire app (I think :-) ProtectionDomain (file:/scratch/iklam/tmp/ <no signer certificates>) sun.misc.Launcher$AppClassLoader@1bc081f <no principals> java.security.Permissions@1d742a1 ( ("java.lang.RuntimePermission" "exitVM") ("java.io.FilePermission" "/scratch/iklam/tmp/-" "read") ) So perhaps we should keep a hashtable of protection domains, and each DictionaryEntry just holds a C pointer to a entry to this table. We need to GC this table during class unloading, but that should be straight forward. BTW, I am not sure why we need a DictionaryEntry::_pd_set that could be appended. As far as I can see, there's only a single place that calls DictionaryEntry::add_protection_domain. I.e., when the class is loaded #0 DictionaryEntry::add_protection_domain () #1 Dictionary::add_protection_domain () #2 SystemDictionary::validate_protection_domain () #3 SystemDictionary::resolve_instance_class_or_null () Did I miss something, or is this a vestigial artifact?
12-07-2013
Might help GC times.
30-05-2013