MAT is useful enough on its own to make me seriously consider Java almost everywhere. So many tricky memory leaks in other languages made completely trivial.
Yes, in many languages you can combine a few things plus a core dump and figure leaks out too... but average people actually use MAT because it's largely transparent, and it can operate on running processes. Very few languages can compete with that in practice, much less with reasonable performance.
Is there a tool for the jvm that can track data locality? TFA mentions three for Linux binaries but that won’t do the mapping to Java source if we can combine them with `java -jar` at all.
It is like others relying on tracking memory allocations. Which has it"s place, but to really analyze memory usage you would need to be able to analyze which "objects" are keeping other objects alive (dominator tree in MAT)
Some of our tools do so much allocation that capturing all the information (using MTuner) to disk and later loading require by itself hundreths of GB.
Instead I've added random sampling - e.g. if ptr % modulo > level - output it or not.
Another factor that slows down is doing a callstack capture. It's not for free at all, like on Windows it has to go through the exception handlers, etc. I think perfetto simply captures the whole stack (need to check again), and then offline decodes it - or something like this.
Windows ETW Tracing can also capture the stack, but I guess it'll incur also some penalty - it can't come for free.
I also wish there was some kind of standard binary format for emitting alloc/free sequences with callstack/etc.
> Instead I've added random sampling - e.g. if ptr % modulo > level - output it or not.
A good alternative that also cuts down on the amount of data significantly is to strip away temporary allocations, say, only emit those allocations which were alive for at least X seconds.
Heaptrack can handle millions of allocations per second, and thanks to the deduplication built into the trace file format combined with zstd compression, the overhead is pretty manageable. It's pretty hard to get "hundreds of GB" of data recorded.
Another thing: you can always just runtime attach and profile a partial time to reduce the amount of data recorded.
Finally: if your tools do so many allocations, maybe you should consider optimizing them...
MTuner exists for Windows which is similar but different. Porting heaptrack is not straight forward, as it heavily relies on libraries that do not work on Windows or do not support Windows executables and debugging information, such as libunwind and elfutils.
18 comments
[ 2.8 ms ] story [ 46.3 ms ] threadYes, in many languages you can combine a few things plus a core dump and figure leaks out too... but average people actually use MAT because it's largely transparent, and it can operate on running processes. Very few languages can compete with that in practice, much less with reasonable performance.
Shameless plug: not sure if I'd call it decent, but you might want to check my Bytehound for more in-depth analysis:
https://github.com/koute/bytehound
Instead I've added random sampling - e.g. if ptr % modulo > level - output it or not.
Another factor that slows down is doing a callstack capture. It's not for free at all, like on Windows it has to go through the exception handlers, etc. I think perfetto simply captures the whole stack (need to check again), and then offline decodes it - or something like this.
Windows ETW Tracing can also capture the stack, but I guess it'll incur also some penalty - it can't come for free.
I also wish there was some kind of standard binary format for emitting alloc/free sequences with callstack/etc.
A good alternative that also cuts down on the amount of data significantly is to strip away temporary allocations, say, only emit those allocations which were alive for at least X seconds.
Another thing: you can always just runtime attach and profile a partial time to reduce the amount of data recorded.
Finally: if your tools do so many allocations, maybe you should consider optimizing them...
Small question, what's the difference between (3) and (4)?