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