Which is just the generic env var override convention for your

server.json

values

or kinda sorta the same

Depends on what makes sense for your deploy

The env vars just get merged into the server.json on start

and use the docker stack file to regulate how much total memory is reserved

just to necro this thread, qq for @bdw429s - I feel like the JVM args here are specifying percentages and ratios while

BOX_SERVER_JVM_HEAPSIZE

is saying 'hey commandbox, use exactly this much as your max heap size' -- this seems like a bit of a philosophical disagreement. given a physical server of RAM constraint X and some number (let's say 1-3) of CFML containers running on it, what's your strategy for provisioning heap sizes? ideally the max of all of them would be greater than the total RAM of the machine on the assumption that not all 3 containers are going to hit max consumption at one time (if indeed the deployment makes that sufficiently unlikely); otherwise you're leaving RAM on the table, yes?

The

MinHeapFreeRatio

is a good one if you are wanting to force GC early. I’ve found that G1GC, though, doesn’t require all of the specific args.

If you use Java 14, which Commandbox and Lucee will run on, you can use the new Z collector: https://www.baeldung.com/jvm-garbage-collectors#6-z-garbage-collector That will be the default collector, from my understanding in Java 20 and up.

Just an update to this thread: We tried out ZGC for a week and it was pretty hairy. Production jvm usage spiked to almost everything the container was given and the JVM wouldn't release it. Locally, even with 12 GB of memory allocated, trying to run our test suites would crash the container. Switched to G1GC with String deduplication and everything appears to be fine (though it's only been a few hours). Some reading online suggests that ZGC is better for huge memory apps (like a terabyte) and that Parallel & G1 remain the best 'general purpose, big but not huge memory' app garbage collectors, with the regular disclaimers of YMMV

I'm curious how much ZGC itself has changed across versions since introduced 🤔

It's worth noting Lucee 5.3.10 and CommandBox 5.9.0 (which I STILL need to write the release blog for) have preliminary support for Java 17 (YMMV)

Java 17 being the LTS version after 11 and java 21 already being worked on!

Oracle did not provide an

--argh-just-make-it-work-like-it-used-to

JVM arg

So every single Java module being accessed via reflection requires an explicit JVM arg per package

Prolly Adopt because it's much easier to package and distribute due to licensing and build availability

It's all the "same Java" technhically speaking

Just a matter of who's build you're using of it

While Oracle's penchant for breaking changes is annoying, both CF engines share blame here. Java 8 introduced the invokedynamic stuff for dynamic JVM langauges to avoid reflection, but neither Adobe nor Lucee put any brain cells into fixing what "wasn't broke"

Except, now Oracle is breaking it and it's one of those "well you've had the last 10+ years to refactor away from reflection but you sat on your laurels"

This is the future reckoning those "illegal reflective access will be removed in later versions" console messages have been warning us about since Java 11 (released 5 years ago)

Anywhoo- if you get around to testing on Java 17, here's what you're looking for and how to fix https://ortussolutions.atlassian.net/browse/COMMANDBOX-1587

I'm unclear if this affects random java libraries which do not use Java modules. But every square inch of the JDK has been modularized for certain.

CF has enjoyed the ability for years of just being able to grab the "reflection hammer" from the toolbox to call whatever the heck it wanted for you