RFR(s): 8235912: JvmtiBreakpoint remove oops_do and metadata_do
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Dec 17 13:59:00 UTC 2019
On 12/17/19 4:21 AM, Robbin Ehn wrote:
> Hi Coleen,
>
> On 12/16/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>
>> http://cr.openjdk.java.net/~rehn/8235912/v1/webrev/src/hotspot/share/prims/jvmtiImpl.cpp.udiff.html
>>
>>
>> + NativeAccess<>::oop_store(_class_holder, class_holder_oop);
>>
>>
>> This should probably be:
>>
>> 41 NativeAccess<IS_DEST_UNINITIALIZED>::oop_store(handle, obj);
>>
>
> I have not seen any stores to oopStorage that use that?
> oopStorage should be 'initialized'.
> So I prefer not adding another decorator if it's not needed.
> That would just be confusing.
It's in the ClassLoaderData initialization. I don't know what it means,
you'd have to ask someone who knows. I don't think it matters though.
Coleen
>
>>
>> You can leave out using OopHandle. I have a patch to add the missing
>> functionality and add it to your code. Actually, I was looking to
>> see how much OopHandle is used to see if it's helping anything and
>> there is a lot of code using it. Most of it is to hide oop* in
>> ClassLoaderData.
>>
>> This change otherwise looks great.
>
> Thanks, Robbin
>
>> Thanks,
>> Coleen
>>
>>
>>> Thanks for having a look, Robbin
>>>
>>> On 12/16/19 1:32 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> 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
>>>>
>>
More information about the serviceability-dev
mailing list