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
