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

[Coleen Phillimore]

Okay, thanks for adding a comment.
Coleen

On 2/6/14 6:52 PM, Oleg Mazurov wrote:
> 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
>>>>
>>>
>>
>