Finding application errors that unnecessarily consume memory - Proposal for SoftXmx

[Ron Pressler]

Hi.

ZGC already has -XX:SoftMaxHeapSize. I think this draft JEP could be of interest to you: https://openjdk.org/jeps/8329758

— Ron

> On 8 May 2025, at 17:01, Reto Merz <reto.merz at abacus.ch> wrote:
> 
> Hi all,
> 
> I wasn't exactly sure which mailing list I should post this to. It's about a kind of "monitoring":
> 
> We are a provider of ERP software written in Java.
> Users can log in to our software and perform various "application-level" tasks there.
> These include, for example, entering master data (addresses, project infos, etc.),
> financial tasks like paying or creating invoices, as well as accounting processes such as payroll.
> 
> A logged-in user has a session. Our software starts multiple JVMs.
> When a user logs in, a decision is made on which JVM their session will run.
> Now, there are some things that are held centrally in caches and therefore do not need to be loaded per session but per JVM.
> Other things, however, are specifically assigned to a session, and only that session needs this data at that moment.
> To find application programming errors that unnecessarily consume a lot of memory,
> we start a relatively large number of JVMs, give them little memory (Xmx), and set -XX:+HeapDumpOnOutOfMemoryError.
> If a session needs a lot of memory briefly, and the JVM throws an OutOfMemoryError, then we have a dump and can examine it.
> 
> Example:
> We start 4 JVMs with Xmx=1GB. If there is exactly 1 session and it briefly requests 1.5GB of memory due to an application error
> then there is an OutOfMemoryError, and we have a HeapDump.
> If we were to run only 1 JVM with Xmx=4GB, then in this case, there would be no OutOfMemoryError, and everything would continue to run.
> Which is actually not bad for the user. However, we find fewer memory problems in our application code this way.
> Because normally, a session needs about 16MB. Of course, there are certain processes that require many times that amount of memory briefly.
> For example, when a session does a payroll run, it might need 50MB of memory for a short time.
> 
> I wanted to ask how others might be doing this. What we are already doing is collecting and monitoring metrics.
> 
> An idea that we have, and which would be very practical for us, is if there were a kind of "soft memory threshold" for the JVM/GC.
> The JVM/GC would then try not to exceed this. If it has to, then the same mechanisms would be useful as for "OnOutOfMemoryError".
> So, no OutOfMemoryError would be thrown, but the JVM could allocate the memory, but a one-time event would be triggered, for example "OnOutOfSoftMemory".
> Analogous to -XX:+HeapDumpOnOutOfMemoryError, there could then be an option -XX:+HeapDumpOnOutOfSoftMemory where a HeapDump is generated.
> Or a -XX:OnOutOfSoftMemory=string to execute a command or script.
> 
> Concrete example:
> The JVM could be set with for example a "SoftXmx=1GB", a "Xmx=2GB", and a -XX:+HeapDumpOnOutOfSoftMemory.
> If we think back to the case from above where 1 session briefly requests 1.5GB of memory,
> then a HeapDump would be created, but everything would continue to run normally.
> 
> Now I wanted to ask if such a feature would be conceivable and what your general thoughts are on it.
> 
> Thank you very much,
> 
> Regards,
> Reto Merz
>