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.spit...@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.spit...@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
>>>
>>
>
