RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer (original) (raw)
David Holmes david.holmes at oracle.com
Tue Feb 19 18:38:29 PST 2013
- Previous message: RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer
- Next message: RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer
- Next message: RFR(XXS): 8007147: Trace event ExecuteVMOperation may get dangling pointer
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]