RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc.
David Holmes
david.holmes at oracle.com
Sun Feb 3 20:48:37 UTC 2019
On 3/02/2019 11:13 pm, zgu at redhat.com 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
>>>>>
More information about the serviceability-dev
mailing list