In general, Adobe tries to set reasonable defaults so you shouldn't have to change them unless: a) there's a security issue and Adobe has recommended you change them b) there's something weird in a CF update/hotfix that may require you to change them for backward compatibility c) you've done extensive tuning and research and proven that adjusting the JVM args improves things

To be honest, even at work where we're running bare Java/Clojure processes, we hardly provide any non-default behavior via JVM options. We add just these four: •

-XX:-OmitStackTraceInFastThrow

-- stops the JVM "optimizing away" the stack trace for repeated exceptions (so we get better logging on failures) •

-XX:+HeapDumpOnOutOfMemoryError

-- if the JVM runs out of memory, this creates a heap dump file which is sometimes useful for debugging the OoM •

-XX:+UseG1GC -XX:MaxGCPauseMillis=100

-- selects the GC algorithm that we have found works best and optimizes for interactive throughput But, frankly, if you don't really understand what the JVM options are/do, you shouldn't change the defaults. It's very easy to create sub-par performance, or even prevent the JVM from starting up at all, especially on older JVMs (we just upgraded to JDK 21 in production -- I really should review the G1/Z1/etc collectors but the above still seems to work really well for us).

Looks like that dates back to Java 1.7 👀 Are you sure it is still needed on more modern JVMs? https://stackoverflow.com/questions/19378921/what-encryption-would-be-used-if-ecc-is-disabled-in-jdk-1-7-jvm

Ideally there would be an official Adobe page you could go to with the recommended java args for each supported CF version, with sections for each JVM version that CF version supports if needed, It would need to be kept up to date as security and JVM requirements change. Requiring JVM tuning knowledge to do CF effectively goes against the whole CF development paradigm, and it's silly for every developer to have to research this stuff independently.

Funnily enough, this coincided today with me researching JDK 21 GC options and reviewing the options (above) and looking at the ZGC -- and deciding that we're probably well enough off with the G1 collector, although we have optimized for small heaps and thus we still need to explicitly select G1 (instead of Serial -- which would be the default for small heaps). The ZGC has even fewer tuning knobs than the G1 collector -- but in both cases Oracle recommends you really try to leave things on the defaults and maybe just tweak

mx

(max heap) and/or the GC pause (which we've adjusted down from the default of 200).

Also, all our strings are dealt with as part of i18n handling so there's almost nothing hard-coded into the app and we cache i18n data for performance -- and because we're using Clojure for that, any repeated i18n keys are already interned as keywords so they are deduplicated automatically without touching the GC stuff.