On 3/02/2019 11:13 pm, [email protected] wrote:
Yep, but It is hard to find out. I can not image this is the first
one,
how we dealt with before?
Removing "_reserve_for_allocation_prefetch" breaks JDK8 tools, how
it
was communicated?
I don't know what you are referring to.
_reserve_for_allocation_prefetch
was moved in 9 from Abstract_VM_Version to ThreadLocalAllocBuffer.
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6525e4ba82a1
It still exists there. And it is a plain int not a perf
counter/variable.
If I use JDK8's jinfo against java process using JDK13, I see following
error:
Right you generally can't use the SA tools from one release with another
release as the SA knows about the internal VM data structures.
Attaching to process ID 31669, please wait...
Error attaching to process: java.lang.RuntimeException: can't determine
target's VM version : field "_reserve_for_allocation_prefetch" not
found in type Abstract_VM_Version
sun.jvm.hotspot.debugger.DebuggerException: java.lang.RuntimeException:
can't determine target's VM version : field
"_reserve_for_allocation_prefetch" not found in type
Abstract_VM_Version
Right as I said it was moved in 9 from Abstract_VM_Version to
ThreadLocalAllocBuffer.
at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:435)
at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.JInfo.main(JInfo.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
va:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
rImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jinfo.JInfo.runTool(JInfo.java:108)
at sun.tools.jinfo.JInfo.main(JInfo.java:76)
Caused by: java.lang.RuntimeException: can't determine target's VM
version : field "_reserve_for_allocation_prefetch" not found in type
Abstract_VM_Version
at sun.jvm.hotspot.runtime.VM.<init>(VM.java:291)
at sun.jvm.hotspot.runtime.VM.initialize(VM.java:370)
at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:431)
... 11 more
I assume that this is the worst case if external tools are not updated
accordingly.
What you encountered here is an issue with using the wrong version of
the SA. Removing a public perf variable/counter is a different scenario,
but would likely lead to a similar exception.
That aside we have in threadLocalAllocBuffer.cpp:
320 return PerfDataManager::create_variable(SUN_GC,
PerfDataManager::counter_name("tlab", name), unit, THREAD);
So these are in the SUN_GC namespace and anything in the sun
namespace
is unstable and unsupported:
hotspot/share/runtime/perfData.cpp
const char* PerfDataManager::_name_spaces[] = {
// top level name spaces
"java", // stable and supported name space
"com.sun", // unstable but supported name space
"sun", // unstable and unsupported name space
So this should be okay.
Thanks for investigating and explaining. Can I take it as "reviewed"?
No sorry I didn't review it. Not at all familiar with TLAB or these
stats. Isn't this more a GC than runtime issue?
David
-----
-Zhengyu
Thanks,
David
-----
Thanks,
-Zhengyu
David
-----
Bug: https://bugs.openjdk.java.net/browse/JDK-8212127
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/
Test:
hotspot_runtime, hotspot_serviceability,
vmTestbase_nsk_monitoring,
vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti,
vmTestbase_vm_jdwp
on Linux x64
Eyeball output of jsnap
Thanks,
-Zhengyu
