RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer

David Holmes david.holmes at oracle.com
Mon Feb 25 00:38:19 PST 2013


Ok. :)

David

On 25/02/2013 6:36 PM, Markus Grönlund wrote:
> Thank you Staffan.
>
> I still need an ok from a (R)eviewer to proceed with this - can I ask for this please?
>
> Best regards
> Markus
>
>
> -----Original Message-----
> From: Staffan Larsen
> Sent: den 20 februari 2013 11:42
> To: Markus Grönlund
> Cc: David Holmes; Dean Long; Erik Gahlin; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer
>
> Looks good!
>
> /Staffan
>
> On 20 feb 2013, at 11:15, Markus Grönlund <markus.gronlund at oracle.com> wrote:
>
>> Thanks for your input on this one.
>>
>> I think I am hearing that we can proceed with assigning a 0 (zero) as the thread id to indicate the thread information is unknown for a non-blocking operation. Risk being of course to have a false "hit" if a 0 is assigned by some OS as a thread id, and even worse if 0 is also re-used across threads. This should be considered low risk. In addition, the occasional wrong info in the caller thread field might not warrant avoiding presenting info about non-blocking operations.
>>
>> Resolving this would incorporate a lot of investigation which must be dealt with outside the scope of this bug.
>>
>> By adding additional comments about this fact (thread 0 being used to indicate "thread unknown" for non-blocking ops) I think we can proceed with a modified version of the first webrev01, but with additional comments added.
>>
>> Updated webrev can be found here:
>>
>> http://cr.openjdk.java.net/~mgronlun/8007147/webrev03/
>>
>> Thanks again
>> Markus
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: den 20 februari 2013 03:38
>> To: Dean Long
>> Cc: Staffan Larsen; Markus Grönlund;
>> serviceability-dev at openjdk.java.net;
>> hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR(XXS): 8007147: Trace event ExecuteVMOperation may get
>> dangling pointer
>>
>> On 20/02/2013 5:30 AM, Dean Long wrote:
>>> On 2/19/2013 11:00 AM, Staffan Larsen wrote:
>>>>
>>>> On 19 feb 2013, at 19:56, Dean Long <dean.long at oracle.com
>>>> <mailto:dean.long at oracle.com>> wrote:
>>>>
>>>>> When the VM_Operation is created, we could take a snapshot of the
>>>>> thread_id of the caller, then use that later.
>>>>
>>>> One problem with that is if the thread_id gets reused for a new
>>>> thread quickly after the old thread terminates. This is perhps
>>>> ulikely, but could happen.
>>>>
>>>>> Or we could block the creating thread from fully exiting until the
>>>>> VM op executes.
>>>>
>>>> That would introduce a lot more synchronization and state to keep
>>>> track of.
>>>>
>>> I think we could do it with a reference count on the thread, a wait
>>> in thread exit, and a notify in the VM thread.
>>> We have a similar dangling pointer problem with JVMTI (7154963), and
>>> a reference count should solve that problem as well.
>>
>> I think that proposal needs a lot more investigation, certainly it is well out of scope for this bug. There are potential dangling thread pointers all over the JVM interfaces.
>>
>> David
>> -----
>>
>>>
>>> dl
>>>
>>>> /Staffan
>>>>
>>>
>


More information about the hotspot-runtime-dev mailing list