RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc.

[zgu at redhat.com]

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