RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects

[coleen.phillimore at oracle.com]

Hi Thomas,  Can you forward the review thread for JDK-8213229?

I wonder if we could just trigger_unloading after any GC has run and 
ignore dead string counts.  Are they ever zero?

Thanks,
Coleen

On 1/28/19 6:45 AM, Thomas Schatzl wrote:
> Hi again,
>
>    cc'ed hotspot-runtime-dev since it concerns the string table.
>
> Also, this patch is based on the changes for JDK-8213229.
>
> Thanks,
>    Thomas
>
> On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this change that tries to fix the issue with
>> the string table reporting too low "dead" numbers to the
>> ServiceThread notification mechanism in the review for JDK-8213229,
>> potentially causing C heap memory being kept live for longer than
>> necessary?
>>
>> This change implements one option for fixing this, in particular that
>> the WeakProcessor calls OopStorage::oops_do() instead of
>> ::weak_oops_do, counting the number of NULL entries manually.
>>
>> There is another, let weak_oops_do() return the number of NULL
>> entries as function return value. However the return value of the
>> used iterate_safepoint() is already in use in some I'd consider
>> interesting test case. I did not want to add another out-parameter
>> either.
>>
>> Since the WeakProcessor has been the main user of the weak_oops_do()
>> method, I would suggest to clean this up preferably in an extra CR:
>> there is still one use of the OopStorage::weak_oops_do() method that
>> could be easily removed. If you think we should not remove it, I
>> strongly suggest to rename the weak_oops_do() methods to better
>> indicate what they actually do instead of giving a very strong
>> (wrong) suggestion where/when they should be used.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8217778
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8217778/webrev/
>> Testing:
>> hs-tier1-5
>>
>> Thanks,
>>    Thomas
>>
>>
>