RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc.
zgu at redhat.com
zgu at redhat.com
Sun Feb 3 13:13:30 UTC 2019
> > 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:
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
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.
>
> 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"?
-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
> > > >
More information about the serviceability-dev
mailing list