Review request: 8009174: add class load event tracing

[Staffan Larsen]

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 post_class_load_event method. I didn't see the changes that used the post_class_load_event 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 (!HAS_PENDING_EXCEPTION && !k.is_null()) {
> 819         // post class load event
> 820         post_class_load_event(starttime, k, class_loader);
> 821
> 822         // class_loader is NOT the defining loader, do a little more bookkeeping.
> 823         if (k->class_loader() != class_loader()) {
> 
> 824
> 825           check_constraints(d_index, d_hash, k, class_loader, false, THREAD);
> 826
> 827           // Need to check for a PENDING_EXCEPTION again; check_constraints
> 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
>>