You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When dumping the heap of a native executable to analyze it in VisualVM, the heap dump is polluted by objects that are created during the heap dump creation.
This makes it hard to analyze smaller heap dumps, especially initial heaps obtained through -XX:+DumpHeapAndExit, as they are often dominated by the objects created during heap dump creation. Here's an example screenshot of a heap dump for a native HelloWorld:
The heap dump pollution can be avoided by using only unmanaged, native memory within the heap dump writer rather than managed, heap-allocated objects.
The text was updated successfully, but these errors were encountered:
It seems that the heap dump writer also allocates numerous strings and other objects. Most notably, it seems to allocate 5700+ strings with a value of utf-8:
How about writing out the metadeta (HeapdumpWriterImpl) needed to write the hprof file to an extra file during generation, later on, when an dump should happen, the file will be mapped into memory and used to write the hprof file.
When dumping the heap of a native executable to analyze it in VisualVM, the heap dump is polluted by objects that are created during the heap dump creation.
This makes it hard to analyze smaller heap dumps, especially initial heaps obtained through
-XX:+DumpHeapAndExit
, as they are often dominated by the objects created during heap dump creation. Here's an example screenshot of a heap dump for a nativeHelloWorld
:The heap dump pollution can be avoided by using only unmanaged, native memory within the heap dump writer rather than managed, heap-allocated objects.
The text was updated successfully, but these errors were encountered: