RFR (M) 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread

[coleen.phillimore at oracle.com]

Gerard, Thank you for reviewing this!

On 1/30/19 4:21 PM, Gerard Ziemski wrote:
> hi Coleen,
>
> Looks good and I’m glad to see "set_item_clean_count/mark_item_clean_count" stuff go away.
>
> #1 In src/hotspot/share/classfile/symbolTable.cpp we no longer need the comment, so should remove it:
>
>   472   if (clean_hint) {
>   473     // we just found out that there is a dead item,
>   474     // which we were unable to clean right now,
>   475     // but we have no way of telling whether it's
>   476     // been previously counted or not, so mark
>   477     // it only if no other items were found yet
>   478     mark_has_items_to_clean();
>   479     check_concurrent_work();
>   480   }
>
> and just have:
>
>   472   if (clean_hint) {
>   473     mark_has_items_to_clean();
>   474     check_concurrent_work();
>   475   }

Yes, that avoids confusion.  Fixed!
>
> #2 For a followup, I think we can do some further simplifications:
>
> a) Combine "mark_has_items_to_clean() and check_concurrent_work()” into one
> b) Possibly eliminate the 3 new APIs: “reset_has_items_to_clean/mark_has_items_to_clean/has_items_to_clean”
>
> But the main task of changing how we trigger the table cleanup looks fine.

I agree.  I was thinking there are some more improvements that can be 
made.  If we find a dead item on insert, set the flag that there's 
something to clean but have the check_concurrent_work() check at some 
later interval and not immediately.  Maybe at safepoint cleanup.

Thanks!
Coleen
>
> cheers
>   
>
>> On Jan 28, 2019, at 4:09 PM, coleen.phillimore at oracle.com wrote:
>>
>> Summary: remove gc timing for short runtime cleanup triggering; make symbol table cleaning triggered automatically on unloading
>>
>> Ran runThese with all Oracle GCs and got similar numbers of symbols unloaded.  Also ran tier1-5.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8213753.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8213753
>>
>> Thanks,
>> Coleen