RFR(s): 8235912: JvmtiBreakpoint remove oops_do and metadata_do

[coleen.phillimore at oracle.com]

I have to think about this.   Could there be breakpoints in old emcp 
methods that we do not remove?   The metadata_do function is trying to 
keep old Methods from being deleted while there are still references to 
them.

http://cr.openjdk.java.net/~rehn/8235912/v1/webrev/src/hotspot/share/prims/jvmtiImpl.hpp.udiff.html 


+ oop* _class_holder; // keeps _method memory from being deallocated


We created the class OopHandle to encapsulate strong oopStorage 
references, although it's missing oop_store.  Can you use that?

Coleen

On 12/16/19 4:47 AM, Robbin Ehn wrote:
> Hi all, please review.
>
> From issue, https://bugs.openjdk.java.net/browse/JDK-8235912:
>
> JvmtiBreakpoints are walked via VMThread oops_do (the breakpoint is in 
> a vm operation) before they are installed in the safeopint and after 
> they have been installed, walked with JvmtiCurrentBreakpoints::oops_do().
> By putting the class holder inside oopStorage there is no need for this.
>
> JvmtiCurrentBreakpoints::metadata_do is not needed because redefine 
> classes actually removes the breakpoints before updating them (so 
> there is no breakpoints to update).
> We can just remove metadata_do.
>
>
> I also removed some unused code.
>
> Changeset:
> http://cr.openjdk.java.net/~rehn/8235912/v1/webrev/
>
> Passes several runs of nsk jvmti/jdi and t1-7.
>
> Thanks, Robbin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20191216/508aceb1/attachment.htm>