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