Thanks Stefan,
Yes, i think it's ok as long as the Klass is not able to "do anything" useful - i.e. the Klass is not able to execute anything which would involve its traceid. So, I would assume the semantics of Klass::restore_unsharable_info() would be similar in nature to a constructor? It prepares the Klass for use. As long as the Klass is coming out "prepared" with a unique ID assigned, this will be fine. Thanks Markus From: Stefan Karlsson Sent: den 24 april 2014 18:30 To: Markus Grönlund; serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses Hi Markus, On 2014-04-24 17:42, Markus Grönlund wrote: Greetings, Kindly asking for reviews for the following very small fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8041723 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8041723/webrev01/"http://cr.openjdk.java.net/~mgronlun/8041723/webrev01/ Klass::restore_unshareable_info() might be called multiple times for a given Klass. This can happen if OutOfMemoryErrors is thrown when the Klass is loaded, and we later retry to load the Klass. Is it OK to call TRACE_INIT_ID(this) multiple times for the same Klass? thanks, StefanK Description: The Event Based tracing framework assigns a unique traceid to Klass:es for tracking purposes. Normally, a new Klass is assigned it's traceid inside the Klass constructor. For Klass:es coming into the system via the ClassDataSharing (CDS) mechanism, the old traceid for the Klass will be stale, hence a "new" traceid needs to be (re)assigned to the Klass. Thank you Markus
