RFR (S) 8178336: Unnecessary SystemDictionary walk for Protection domain liveness

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Tue Apr 11 13:03:26 UTC 2017



On 4/11/17 2:35 AM, Ioi Lam wrote:
> Hi Coleen,
>
> Thanks for doing this clean up. I was guiltily of writing the original 
> code :-(
>
> A few questions:
>
> Why is this block of code moved and the comments dropped?
>
>  328 void Dictionary::oops_do(OopClosure* f) {
>  329   // Only the protection domain oops contain references into the 
> heap. Iterate
>  330   // over all of them.
>  331   _pd_cache_table->oops_do(f);
>  332 }
>  333
>
> It would be better to make the changes in-place.

I didn't have to change Dictionary::oops_do and moved it to be near 
always_strong_oops_do(), so I shouldn't have removed the comment.  I 
moved it back but I don't like that it's separated from the other GC 
functions.   With my other change, it'll be closer (I think I'm going to 
have a merge conflict with myself).
>
> Also, have you validated that (either with an explicit test, or inside 
> the debugger)
>
> [1] live protection domains in _pd_cache_table are properly relocated 
> during GC?
> [2] dead protection domains are removed after class unloading?

I ran with runThese (which has lots of class loading and unloading) with 
logging for both oops_do and unlink functions (removing protection 
domain entries)  but I didn't realize that always_strong_oops_do is 
never called, so I deleted this function.

New webrev (with dictionary::oops_do put back):

http://oklahoma.us.oracle.com/~cphillim/webrev/8178336.02/webrev/index.html

Thanks!
Coleen
>
> Thanks
> - Ioi
>
> On 4/11/17 4:18 AM, coleen.phillimore at oracle.com wrote:
>> Summary: remove system dictionary walk and pass strong closure for 
>> !ClassUnloading
>>
>> See bug for more details:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8178336.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8178336
>>
>> Tested with nightly tier2-5 tests and jprt (runs all GCs) and 
>> runThese with -XX:-ClassUnloading.
>>
>> Thanks,
>> Coleen
>



More information about the hotspot-dev mailing list