JDK-8139673 : NMT stack traces in output should show mt component
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-10-15
  • Updated: 2019-05-22
  • Resolved: 2017-05-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8
10 b21Fixed 8u172Fixed
Related Reports
Relates :  
JDK-8218558 - NMT stack traces in output should show mt component for virtual memory allocations
Relates :  
JDK-8184991 - NMT detail diff should take memory type into account
Description
Eg. this is a snippet of current output from jcmd <pid> VM.native_memory detail

[0xf6c6e7ff] NativeCallStack::NativeCallStack(int, bool)+0x5f
[0xf6db2880] Symbol::operator new(unsigned int, int, Thread*)+0xf0
[0xf6db4384] SymbolTable::basic_add(int, unsigned char*, int, unsigned int, bool, Thread*)+0x154
[0xf6db44f5] SymbolTable::lookup(char const*, int, Thread*)+0xe5
                             (malloc=22KB #299)

[0xf6c6e7ff] NativeCallStack::NativeCallStack(int, bool)+0x5f
[0xf66cb395] ChunkPool::allocate(unsigned int, AllocFailStrategy::AllocFailEnum)+0x125
[0xf66ca15d] Arena::Arena(MemoryType, unsigned int)+0x14d
[0xf6c0377d] Matcher::Matcher()+0x4d
                             (malloc=20KB #2)

[0xf66cb4a4] CHeapObj<(MemoryType)7>::operator new(unsigned int)+0x84
[0xf683c7a6] ClassLoaderData::anonymous_class_loader_data(oopDesc*, Thread*)+0x106
[0xf6dc293a] SystemDictionary::parse_stream(Symbol*, Handle, Handle, ClassFileStream*, KlassHandle, Growabl
eArray<Handle>*, Thread*)+0xba
[0xf6e141bd] Unsafe_DefineAnonymousClass+0x5fd
                             (malloc=19KB #201)

[0xf6c6e7ff] NativeCallStack::NativeCallStack(int, bool)+0x5f
[0xf69f54e6] BasicHashtable<(MemoryType)9>::new_entry(unsigned int)+0x166
[0xf69f5538] Hashtable<Symbol*, (MemoryType)9>::new_entry(unsigned int, Symbol*)+0x18
[0xf6db4341] SymbolTable::basic_add(int, unsigned char*, int, unsigned int, bool, Thread*)+0x111
                             (malloc=16KB #4)

It would be nice if these were annotated with mtClass mtCompiler or mtSymbol
Comments
I got a new request for this capability. Max did a great job and already provided most of functionality. The patch only needs a few twists to resolve the ambiguous/incorrect memory tagging, as Coleen suggested. As Chris mentioned, most allocation sites likely only associate with single memory type, so that should not result much more memory usage in product build by NMT. I re-open this bug, as it can be useful functionality.
22-05-2017
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-January/022345.html It's not straightforward, closing as WNF.
08-03-2017