I have been told this before too.
Currently I can't run my integration tests on my work laptop because they spin up a bunch of "micro" services, so I run out of ram and need to reboot.
The memory that Java "doesn't require" really adds up.
I believe that is why the original Java answer to microservices was EARs all within a single app server so they could share a JVM and caching. Then in production for load you could spread them all out and they can find eachother... but I've never worked in actively developed JEE (as opposed to a legacy one).
Re:FF4J – Feature Flags for Java
by imtringued on Thursday June 08, 2023 @02:07PM
(#36246113)
It's especially bad when you have to run both IntelliJ with multiple projects and grails.
Java by default allocates a healthy percentage of available RAM. It releases memory if a large percentage is unused, and it only runs full GC when a large percentage is used. The trick is therefore to decrease the initial max memory. Otherwise you can wind up with 70% usage, a lot of objects that could be GC'd but are not because there is not enough memory pressure to run full GC, and there is not enough unused memory to be able to release RAM back to the OS
Re:FF4J – Feature Flags for Java
by ye-olde-sysrq on Wednesday June 07, 2023 @01:59PM
(#36230676)
See my reply to the other comment - I specifically refer to off-heap memory, not on-heap/GC-managed memory.
Re:FF4J – Feature Flags for Java
by ye-olde-sysrq on Wednesday June 07, 2023 @01:58PM
(#36230664)
I'm here specifically referring to off-heap memory. I verified this by looking into the jvm with VisualVM. These are objects that aren't part of the normal java heap area and aren't part of garbage collection. The offheap can contain many things - classloaded code, memory-mapped files, direct bytebuffers, and so on. And since it's offheap, it's hard to analyze from Java tooling. So I literally don't know what it was doing.
So in my above scenario, I could indeed run the app with a -Xmx32M and yet the application was still using 200-300MB of resident memory (RSS) due to offheap usage.
You can use native memory tracking to better inspect offheap usages. I had a similar problem where the default MaxMetaspaceSize was excessive and adjusted it to a reasonable setting.
-XX:NativeMemoryTracking=summary
jcmd <pid> VM.native_memory summary
I think Java tends to grow memory usage up to a point, rather than to try and release it at the cost of performance. That doesn't mean it would not be able to run on a machine with lower memory. It could run more expensive GC if it was needed