Thank you for answering my question, Coleen!
Serguei

On 7/23/20 04:36, coleen.phillim...@oracle.com wrote:


On 7/22/20 8:53 PM, serguei.spit...@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.phillim...@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



Reply via email to