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

[Oleg Mazurov]

My understanding was that a buffer blob was just that - a buffer. Could potentially contain code fragments of different kinds.
Thus, is_buffer_blob() was the closest type available. Agree that a dependency on its name is not reliable, though testing 
will reveal if the condition turns false for "vtable chunks" due to a name change (I had to deal with that particular test, Serguei
should be able to identify it). Adding a comment to where the name is defined (vtableStubs.cpp) that such a dependency exists
is a good idea.
Thanks,

    -- Oleg

On Feb 6, 2014, at 3:32 PM, Coleen Phillimore wrote:

> 
> 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 
>>> 
>> 
>