Java Memory Analyzer
heaphero.io
heaphero.io
Uploading a bunch of stack traces to generate a flame map is one thing, but the heap can have secrets and keys and so on in memory.
In my eyes, anyone using such a service is as careless as someone posting unencrypted lists of his passwords hidden in Lorem Ipsum texts on Facebook so he can look them up if he forgets one. Any sane corporate data protection rulebook should prohibit the use of such services and consider any potential surreptitious use a harsh breach of trust and thus a cause for termination of the employment.
https://heaphero.io/heap-terms.jsp: >Software applications generate a specialized type of log file. These log files are hard for engineers to interpret and troubleshoot. Using the Site, users can upload log files and we parse, analyze, and generate root cause analysis reports instantly.
>By uploading log files or leaving us feedback, you may provide text, images, software, videos and/or other material, including third party content ("User Content") that you share using the Site.
>Your User Content belongs to you (or to the relevant third parties). However, you grant the Company the following non-exclusive license: a worldwide, transferable and sub-licensable right to use, copy, modify, distribute, publish, and process, information and your User Content that you provide through the Site, without any further consent, notice and/or compensation to you or others. You also grant us the right to use your log files to enhance the performance of our Services.
Not that I would trust even a perfect privacy policy when it comes to uploading heapdumps.
There are however some websites that work completely offline (you download the HTML page and there is no network IO), like CyberChef [1] or the Spotify thread dump analyzer [2].
And for heap dumps, just use Eclipse MAT [3].
[1] https://gchq.github.io/CyberChef/ (yes, that GCHQ)
Ever wondered when the most recent leak of your most valuable secrets occurred? Simply upload your password file to my web service and within moments the magic of our distributed AI will return the current date/time...
Doesn't cynically take passwords, but could in theory harvest emails.
Still, even offering the public upload option is a serious concern. They'd be better suited offering a download with free tier limitations.
Definitely do not use their cloud service to analyze heap dumps out of production. You will probably be leaking sensitive company secrets, and, if your company's data handling policies are at all reasonable, you'll probably also be violating legal obligations to your clients, as well as their trust.
Doing it for development may be safer, insofar as it it's more likely to merely be dangerous, but not also tortious or unethical.
Android also has quite capable profilers.
$ java -XX:StartFlightRecording:settings=profile MyApp
$ jcmd MyApp JFR.dump paths-to-gc-root=true filename=dump.jfr
$ jfr print --events OldObjectSample --stack-depth 64 dump.jfr
The tool will list objects on the heap, their path to the GC roots and allocation stack trace. That is usually sufficient to solve the memory leak. No need to create a large HPROF file or upload data to a server. Everything can be done in the shell.
https://docs.oracle.com/en/java/javase/13/troubleshoot/troub...
Sensitive information, like credit card numbers, will not even leave the Java heap.
I've found out that vmmap (as shown here[1]) is only a little helpful, as it has so much info I can't really make sense of it... and I also found this[2] answer on StackOverflow that was very helpful as it lets me see the native memory allocation by the JVM... but all I know now is that less than half of my JVM memory consumption is the actual heap: the rest is thread stacks (huge for JavaFX - around 50MB for my app), GC-allocated memory and around 25MB of class definitions!
[1] https://plumbr.io/blog/memory-leaks/why-does-my-java-process...
[0]: https://visualvm.github.io/
I've used this a couple of times to profile running servers. Not perfect but it lets you profile memory and cpu usage. Visualvm is a PITA to get working over ssh.
However, in the VisualVM downloads page[2], they say:
"VisualVM has also been distributed in Oracle JDK 6~8 as Java VisualVM. It has been discontinued in Oracle JDK 9. See the Upgrading Java VisualVM page to learn how to upgrade to the latest VisualVM."
That's confusing wording: it sounds like they did "discontinue" something... I think they mean it just stopped being bundled with the JVM, which is not the same thing as discontinuing it.
[1] https://www.infoq.com/news/2018/06/open-source-jmc/ [2] https://visualvm.github.io/download.html