RFR (S) 8249822: SymbolPropertyTable creates an extra OopHandle per entry

[coleen.phillimore at oracle.com]

Thanks Serguei!
Coleen

On 7/23/20 3:18 PM, serguei.spitsyn at oracle.com wrote:
> Thank you for answering my question, Coleen!
> Serguei
>
>
> On 7/23/20 04:36, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 7/22/20 8:53 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Coleen,
>>>
>>> The fix looks good to me.
>>
>> Thank you for looking at this Serguei.
>>>
>>>
>>> On 7/22/20 13:55, coleen.phillimore at oracle.com wrote:
>>>> Summary: Add an assert to OopHandle assigment operator to catch 
>>>> leaking OopHandles, and fix code accordingly.
>>>>
>>>> There are some jvmtiRedefineClasses.cpp changes here - basically, I 
>>>> moved the RedefineVerifyMark and comments into 
>>>> jvmtiRedefineClasses.cpp because I needed a Handle.
>>>
>>> I think, the jvmtiRedefineClasses.cpp is a better place for the 
>>> RedefineVerifyMark.
>>> But could you, please, explain a little bit more why this move was 
>>> necessary?
>>> Why Handle can not be used in the jvmtiThreadState.cpp?
>>
>> I did have a patch where I moved the constructor and destructor in 
>> jvmtiThreadState.cpp but thought it made more sense just to move the 
>> whole class since nothing else would ever use it.   I couldn't put 
>> the code change in jvmtiThreadState.hpp in place because I'd need to 
>> include handles.inline.hpp there.  It seems like 
>> jvmtiRedefineClasses.cpp already included all the files it needed, so 
>> that's where I moved it.
>>
>> Thanks,
>> Coleen
>>
>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>>> Ran tier1-6 tests and tier1 on all Oracle platforms.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2020/8249822.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8249822
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>