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

[coleen.phillimore at oracle.com]

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
>