On Tue, 5 Dec 2023 01:41:33 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> I was actually referring to the footprint of the hprof file, not the in > process memory usage while producing it. > > My concern with not doing the option to exclude stack traces now is that it > could result in some unusable or unmanageably large heap dumps, or tools > simply being overwhelmed by the number of threads. For example, I just looked > at the VisualVM threads view, and it just produces a scrollable list of all > threads. What happens if there are suddenly 10's of thousands if not millions > of threads? If we are lucky is doesn't choke on them and the platform threads > are first in the list, but this is the type of thing I'd like to see testing > of before pushing this change. Heap dumps are usually big. I think stack traces would not add much (comparing to the size of heapdump itself). Also heap dumper supports compression. It works perfectly fine for identical stack traces. I did some experiments with VisualVM and Eclipse MAT using a heapdump which contains 5K virtual threads. VisualVM has a bug which causes failure populating thread list (I filed a bug for it). I fixed the bug locally and VisualVM was able to generate the list. VisualVM is not ready to work with bug number of threads - it generates the whole list of the threads with stack traces and locals before show it (as table rows or as html) and the generation takes long time. I'd say this is VisualVM's UI issue. I generated heap dump without stack traces - it doesn't help much. Eclipse MAT handles 5K vthreads with no problem (no noticeable lags with and without stack traces). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16665#issuecomment-1844052655
