Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced

[Coleen Phillimore]

Hi, I clicked on this a couple times.  It seems okay but isn't there a 
safer way to identify code blobs that are vtable stubs, without looking 
at the name (which can change in while creating it).  A comment at least 
when you create "vtable chunks" would be good.   It seems that someone 
might want to rename it "vtable or itable buffers", or something like that.

thanks,
Coleen

On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote:
> Runtime team,
>
> This fix was reviewed by Vladimir K. and me.
> Just wanted to make sure if you would like to review it as well.
> If not, then I will push it.
>
> Thanks,
> Serguei
>
> On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-8025841
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 
>>
>>
>> Summary:
>>
>>   The fix contributed by Oleg Mazurov to improve profiling data quality.
>>   It moves the "vtable stub" dynamic code notification to the right 
>> place.
>>   I've already reviewed the fix, and it looks good to me.
>>
>>   Bug report description:
>>
>>    "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets 
>> scheduled when
>>     a new chunk of memory for subsequent vtable and itable stubs is 
>> allocated.
>>     That chunk is uninitialized (contains zeros or garbage) although 
>> due to the fact
>>     that the actual event delivery is deferred, at least one vtable 
>> comes out right.
>>
>>     This event should describe an individual vtable/itable stub (base 
>> address and size)
>>     and only after it's been created (memory is actually populated 
>> with code).
>>     Where VM diagnostic messages about vtable/itable stubs are issued 
>> upon
>>     -XX:+PrintAdapterHandlers appears exactly the right place for 
>> JVMTI events as well.
>>
>>     Getting vtables/itables right is important in the context of 
>> performance analysis as
>>     that dynamically generated code may accumulate quite noticeable 
>> CPU time
>>     (especially itabes), sometimes larger than the actual Java 
>> methods called."
>>
>>
>> Testing:
>>   Oleg tested it in the Oracle Studio Performance Analyzer environment.
>>   nsk.jvmti, nsk.jdi, nsk.jdwp,
>>   In progress: Jtreg com/sun/jdi, java/lang/instrument
>>
>>
>> Thanks,
>> Serguei
>>
>