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

Markus Grönlund markus.gronlund at oracle.com
Wed Feb 20 02:15:17 PST 2013

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 VMOperation is created, we could take a snapshot of the threadid of the caller, then use that later. One problem with that is if the threadid 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 serviceability-dev mailing list