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