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