
Java Memory Analyzer - Ram_Lakshmanan
https://heaphero.io/
======
fnord123
Am I alone in thinking things like online pastebins, base64encoders/decoders,
online heap analysers, online json linters, etc are all security issues where
the sites can just harvest tons of data?

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.

~~~
thombat
On these lines, allow me to introduce a valuable new service: MRLTaaS (Most
Recent Leak Time as a Service)

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...

~~~
fnord123
I found one that checks your hmac generation:
[https://www.freeformatter.com/hmac-
generator.html](https://www.freeformatter.com/hmac-generator.html)

------
grandinj
I can recommend the Eclipse MAT tool if you want to do this kind of thing
locally. A little awkward when you need to do advanced searches through the
heap, but generally pretty good.

~~~
pjmlp
Or the NetBeans built-in profiler as well.

Android also has quite capable profilers.

------
haglin
The JDK comes with a powerful memory leak tool.

$ 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...](https://docs.oracle.com/en/java/javase/13/troubleshoot/troubleshoot-
memory-leaks.html#GUID-FA5677A5-B175-40B4-B7F0-851118B6B7AD)

Sensitive information, like credit card numbers, will not even leave the Java
heap.

------
brabel
I have a JavaFX app which is consuming far more memory than the heap
allocates... even when I set Xmx. For example, with java -Xmx64m I can see
that the app runs just fine, but it still consumes over 200MB according to the
OS (checked with htop and with Mac's System Monitor). Does anyone know a tool
to help find out why the JVM is holding on to so much memory beyond the heap,
or how to make the JVM use less native memory?

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...](https://plumbr.io/blog/memory-leaks/why-does-my-java-process-
consume-more-memory-than-xmx)

[2]
[https://stackoverflow.com/a/30941584/1007991](https://stackoverflow.com/a/30941584/1007991)

~~~
wlkr
Have you tried VisualVM [0,1,2]? I've found it pretty easy to use. I'm not
sure how helpful it will be for native memory, however (likely not much!).

[0]: [https://visualvm.github.io/](https://visualvm.github.io/)

[1]:
[https://en.wikipedia.org/wiki/VisualVM](https://en.wikipedia.org/wiki/VisualVM)

[2]: [https://visualvm.github.io/](https://visualvm.github.io/)

~~~
brabel
That's the oldest tool in the Java dev toolbox... but it only shows heap usage
and metaspace. Also, after Java 9+ they seem to have retired jvisualvm and the
tool to use now is
[https://wiki.openjdk.java.net/display/jmc/Main](https://wiki.openjdk.java.net/display/jmc/Main)

~~~
kevinherron
VisualVM is still being developed:
[https://visualvm.github.io](https://visualvm.github.io)

~~~
brabel
Yeah, I saw that... last release was just a few days ago... I thought that
since the Java standard distribution stopped shipping it, it would just die
off and JMC would become the new standard tool... knowing that it's still
alive makes me very happy, especially after Oracle fired the whole team
working on JMC[1] immediately after open-sourcing it..

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/](https://www.infoq.com/news/2018/06/open-source-jmc/) [2]
[https://visualvm.github.io/download.html](https://visualvm.github.io/download.html)

------
sgt
Uploading a 16GB file (less when compressed) doesn't sound too much fun. I
prefer just using a local tool

------
mister_hn
No thanks, I will prefer jprofiler.. A local tool is 100x better than a cloud
one, especially when dealing with sensitive content

------
mpalfrey
+1 for Eclipse MAT. It works well for me.

