set MaxDirectMemorySize, reconsider `Xmx` default size

I discovered that setting the Java option -XX:MaxDirectMemorySize is effective at limiting the game’s seemingly limitless hunger for memory outside the Java heap. I don’t know what heuristic it uses by default, but my processes were regularly multiple gigabytes larger than Xmx led me to believe they should be. (As measured by looking at the process in Linux and noting its Resident Set Size or data+stack size as in #4946).

A value of -XX:MaxDirectMemorySize=512M was sufficient to run a single-player game of Metal Renegades with “Moderate” view distance (plus 6 LOD).

Looking at how much of the process’s memory is not in the Java heap also made me reconsider what value we use for that by default. We currently give it a whopping three gigabytes in development workspaces: https://github.com/MovingBlocks/Terasology/blob/984d9e94e2be5084e2b8a121908070537486252f/build-logic/src/main/kotlin/org/terasology/gradology/exec.kt#L16

—but that single-player MR game seemed content with only a quarter of that (768M).

Places to adjust this:

• build-logic/exec.kt
  • change DEFAULT_MAX_HEAP_SIZE
  • add an @Option to set MaxDirectMemorySize, provide a default
• IntelliJ run configs?
• Launcher. If I recall correctly, it has UI in settings for Xmx. I don’t remember if it sets it by default. I think it also allows you to set additional arbitrary java arguments, but I think it would be worth it to provide explicit support for this one so we don’t rely on users remembering to add it.

Considerations:

Why did we set DEFAULT_MAX_HEAP_SIZE so high? (I think that change was within the last year or two.)

[jdrueckert]

From what I saw, memory consumption never went above 3G according to my resource monitor. Would be interesting to see how it behaves in multiplayer testing on the server. But considering that there were no crashes, I’d argue that we can try the memory restriction and if we receive error reports, we can still increase it…? @keturn

[keturn]

I guess I’m not too surprised to hear it requires hacky workarounds to access at runtime, given that it’s an implementation-specific flag set with -XX.

It looks like one way to check is to add the -XX:+PrintCommandLineFlags flag. With that I get:

Task :facades:PC:game -XX:G1ConcRefinementThreads=8 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=261478272 -XX:+ManagementServer -XX:MaxDirectMemorySize=536870912 -XX:MaxHeapSize=805306368 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC 11:51:52.027 [main] INFO org.terasology.engine.Terasology - homeDir is .