RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses
markus.gronlund at oracle.com
Thu Apr 24 16:41:48 UTC 2014
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.
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
On 2014-04-24 17:42, Markus Grönlund wrote:
Kindly asking for reviews for the following very small fix:
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?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev