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

Markus Grönlund markus.gronlund at oracle.com
Tue Feb 19 01:47:39 PST 2013

Hi David,

Thanks for taking a look.

The original idea was to use thread id 0 as a signal for "Unknown Thread" or "no thread" if you like - however, there is nothing actually enforcing this; it was more of an implicit assumption (and to be honest, the only OS which I know for sure will never give a tid of 0 is Windows). I have tried to find information if a 0 will ever be given out by pthreads and mach_t, but I mostly find info on "process relative opaque id"...so it could be likely that a 0 is used as a valid tid here (probably unlikely but still...)

Also, I see that the tracing output just happily gives out tid == 0 if I write it in as suggested in webrev01...I am not entirely happy with this. If we view 0 as "Unknown Thread", this should maybe be treated differently.

I don't know yet what Id I will be able to use here to signal the fact that thread is unknown (in a platform agnostic way) - but I will try to come up with something.

In the interim, we should just avoid committing the event for non-concurrent VM operations event altogether (I have mostly seen these as EnableBiasLocking and Thread.Stop's).

The updated webrev02 gives a suggestion on only committing the tracing event for non-concurrent vm ops:

http://cr.openjdk.java.net/~mgronlun/8007147/webrev02/

(follow up work will also need rework the event fields).

Thanks Markus

-----Original Message----- From: David Holmes Sent: den 18 februari 2013 05:06 To: Markus Grönlund Cc: 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

Hi Markus,

So is zero as a thread id defined to mean "no thread" ?

David

On 13/02/2013 12:03 AM, Markus Grönlund wrote:

Greetings,

Kindly asking for reviews and a putback sponsorship for the following change: Bugid: http://bugs.sun.com/viewbug.do?bugid=8007147 Webrev: http://cr.openjdk.java.net/~mgronlun/8007147/webrev01/ Please also note this is for hs24. Thanks to David Holmes for pointing out this problem. Thanks Markus

More information about the serviceability-dev mailing list