RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses

[Markus Grönlund]

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 at openjdk.java.net serviceability-dev at 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

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140424/902bb567/attachment.html>