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

[Markus Grönlund]

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
>>
>