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

[serguei.spitsyn at oracle.com]

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
>>
>