Review request: 8009174: add class load event tracing (original) (raw)

Staffan Larsen staffan.larsen at oracle.com
Fri Mar 1 00:31:07 PST 2013

On 1 mar 2013, at 08:59, David Holmes <David.Holmes at oracle.com> wrote:

On 1/03/2013 5:37 PM, Staffan Larsen wrote:

On 1 mar 2013, at 07:57, David Holmes <David.Holmes at oracle.com> wrote:

Hi Calvin,

So this adds the code that would allow for the event tracing but it doesn't actually add the code that will do the event tracing ??? It does add the code that creates the event and pushes it into the event tracing framework. This is all that is required to add a new event to the event tracing. Now that was weird. When I loaded the webrev the systemDictionary.cpp change stopped just after the postclassloadevent method. I didn't see the changes that used the postclassloadevent method.

Aha!

So now that I can see them ... the event is being recorded prematurely:

816 // If everything was OK (no exceptions, no null return value), 817 // post a class load event. 818 if (!HASPENDINGEXCEPTION && !k.isnull()) { 819 // post class load event 820 postclassloadevent(starttime, k, classloader); 821 822 // classloader is NOT the defining loader, do a little more bookkeeping. 823 if (k->classloader() != classloader()) { 824 825 checkconstraints(dindex, dhash, k, classloader, false, THREAD); 826 827 // Need to check for a PENDINGEXCEPTION again; checkconstraints 828 // can throw and doesn't use the CHECK macro. The class isn't really loaded until it has passed the loader constraint check. And later the protection domain validation check could fail.

I brought this up earlier as well and the answer had to do with the event reporting both the initiating and the defining class loader (as opposed to the JVMTI event which only reports the defining class loader).

Second problem: you can't store raw oops into the event. Even if classloader oops were somehow non-moving, the loader may not exist at the time the event is examined. You can store raw oops into the event. We take care to make sure they are never referenced after the commit() is called. Sorry I misread the code. You don't store the loader oop you store the klass() - so this just records the type of the Loader rather than identifying the actual instance. What do you do with these values - just treat them as addresses that you print? (Same question if you store oops - what can you do with an oop you can't reference?)

When the event is printed (further down in the commit() chain) the names of the classes will be included.

/Staffan

David

/Staffan

David On 1/03/2013 9:24 AM, Calvin Cheung wrote: This change is for adding the class load event tracing. The event will include the following fields: loaded class defining class loader initiating class loader webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ thanks, Calvin

More information about the hotspot-dev mailing list