G1 garbage collection Ext Root Scanning time increases due to Class.forName (Problem, Solution, and Patch)
Ioi Lam
ioi.lam at oracle.com
Fri Jul 12 11:08:51 PDT 2013
On 07/12/2013 12:22 AM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2013-07-11 at 14:39 -0700, Ioi Lam wrote:
>> While looking at this, I found a small optimization opportunity:
>>
>> void Dictionary::oops_do(OopClosure* f) {
>> for (int index = 0; index < table_size(); index++) {
>> for (DictionaryEntry* probe = bucket(index);
>> probe != NULL && probe->pd_set() !=
>> NULL;
>> probe = probe->next()) {
>> probe->protection_domain_set_oops_do(f);
>> }
>> }
>> }
>>
>> We can sort each bucket so that all the classes that do NOT have a
>> protection domain are placed at the end of the list, so we can skip
>> them
>> easily. However, this won't save too much time, as the GC bottleneck
>> (at least with the original test case) seems to be here:
> the CR at http://bugs.sun.com/view_bug.do?bug_id=8003420 comes to my
> mind every time somebody is talking about system dictionary performance:
> this might be a worthwhile change; during young gc we could then just
> skip the rest of the bucket as soon as the PD is NULL....
>
> Still the scanning time would be dependent on the number of buckets, so
> if the allowable/typical bucket load is high, this might be worth
> trying.
>
> Just an idea,
> Thomas
|Currently all classes loaded outside of the boot loader will have a
protection domain -- so even if we sort the buckets, if you have lots of
classes loaded, most of them will be non-boot classes so this
optimization won't buy you much.||
||
||Anyway, 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 at 1bc081f|||
||| <no principals>|||
||| java.security.Permissions at 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?
I'll look into this ...
- Ioi
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130712/514f40f2/attachment.html
More information about the hotspot-runtime-dev
mailing list