RFR (XS) 8210559: ClassLoaderData Symbols can leak

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Fri Sep 14 13:04:02 UTC 2018


Thanks Ioi!
Coleen

On 9/13/18 9:54 PM, Ioi Lam wrote:
> Looks good. Thanks!
>
> - Ioi
>
>
>
> On 9/13/18 2:53 PM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 9/12/18 8:03 PM, Ioi Lam wrote:
>>> Hi Coleen,
>>>
>>> The changes look good.
>>>
>>> I am wondering if we should add a WhiteBox function to test whether 
>>> a given Symbol is alive. That way, you can write a test case to 
>>> ensure that after the CLD is destroyed, its name will be removed 
>>> from the SymbolTable.
>>>
>>> I know tests cases are a hassle, but I think in the long run that 
>>> would be beneficial.
>>
>> I adapted an existing test and added a whitebox function for return 
>> symbol refcount, which is verified in the test.
>>
>> http://cr.openjdk.java.net/~coleenp/8210559.02/webrev/index.html
>>
>> Thanks,
>> Coleen
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>>
>>> On 9/12/18 4:32 PM, coleen.phillimore at oracle.com wrote:
>>>> Summary: unrefcount the symbol names when the CLD is destroyed
>>>>
>>>> I was going to clean up the sometimes null value of _name and 
>>>> _name_and_id, and have the boot classloader data have a name, but 
>>>> there's a bootstrapping problem.  NULL CLD is created before the 
>>>> SymbolTable.  So this wasn't done.
>>>>
>>>> Tested with mach5 hs-tier1-3, and runThese jck which does a lot of 
>>>> class unloading.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8210559.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8210559
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>
>>
>



More information about the hotspot-runtime-dev mailing list