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; [email protected];
[email protected]
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 <[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
