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

[Dean Long]

What's the cost for adding a new BufferBlob subtype?  We already have 
AdapterBlob and MethodHandlesAdapterBlob.

dl

On 2/6/2014 3: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
>>>>