Looks good! /Staffan
On 20 feb 2013, at 11:15, Markus Grönlund <[email protected]> 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; [email protected]; > [email protected] > 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> >>
