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

Markus Grönlund markus.gronlund at oracle.com
Thu Apr 24 17:06:36 UTC 2014

Thanks Coleen,


It's just a simple scalar assignment - it's ok to take yet another incremented value if needed.




From: Coleen Phillimore 
Sent: den 24 april 2014 18:56
To: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses



On 4/24/14, 12:41 PM, Markus Grönlund wrote:

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.

Stefan is right.   It's sort of a restartable constructor.   We keep the values "restored" so far if you get OOM while restoring the values.  You could conditionally if DumpSharedSpaces not initalize this field in the Klass constructor and check if it's zero before calling TRACE_INIT_ID, if TRACE_INIT_ID has side effects you only want once.  I was thinking earlier that it stores some sort of scalar to this field and that would be ok to do more than once.


As long as the Klass is coming out "prepared" with a unique ID assigned, this will be fine.

So in the rare case of OOM during restore_unshareable_info, you might get an extra unique value if the class is successfully loaded again (which is also rare except in our testing apparently).

I think this fix is good.







From: Stefan Karlsson 
Sent: den 24 april 2014 18:30
To: Markus Grönlund; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net HYPERLINK "mailto: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:



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?




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



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

More information about the hotspot-runtime-dev mailing list