TripleA optimized JVM switches
-
Hi,
Since I got an 'out of memory error' playing Greyhawk Wars, I looked into the vmoptions file and did some testing.
For your information, the best conf I got for Greyhawk Wars (and probably others) is the following:-XX:InitialHeapSize=6G
-XX:MaxHeapSize=6G
-XX:MetaspaceSize=64M
-XX:MaxMetaspaceSize=64M
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSParallelRemarkEnabled
-XX:+CMSParallelInitialMarkEnabled
-XX:NewRatio=2You are supposed to use the latest oracle (HotSpot) 1.8 JRE, and need at least 8 GB memory. With this conf, throughput stays over 98% and max pause is below 1 second.
G1 is not good because of Humongous allocations and to-space exhaustion, CMS seems to be the best compromise. -
@ayoross Wow, that's a lot of memory... I think the default is 1G heap. Surprised you needed to set it that high.
-
It seems the hard AI uses a lot of memory, 1 GB is clearly not enough.
-
@ayoross Yeah, the AI utilizes the battle calculator which makes copies of the entire game data but I tend to set it to 2G heap and don't seem to have issues. Do you have any example save games that seem slow or get OOM if you set it to 2G? I'm thinking of changing the default to 2G but if there is reason to set it higher we could consider that.
-
With a 2 GB heap you will have to wait longer to reach the point where the throughput collapses (and eventually an OOM event happens). When playing a full AI Greyhawk Wars game, there's always at least 1 GB of tenured space used, leaving few space for the rest.
Furthermore, if the young gen size is below 2 GB, you will have very frequent minor GC events, badly affecting the throughput.I used the adaptive mode of the old gc (UseAdaptiveSizePolicy) to find the right heap size value with a throughput target of 98% (GCTimeRatio=49).
I'm sorry I discarded all the gc logs I used for testing at different heap size/algorithm, and I do not make any savegame (full AI). I would recommend setting the heap to 4 GB minimum, with a 2 GB eden space (NewSize=MaxNewSize=2G) and enabling CMS (UseParNewGC, UseConcMarkSweepGC).
-
Another game that relies heavily on conditions and triggers is "Blue Vs Gray". Don't let the graphics fool you this is a well made game (very under rated). Just it bogs way down if guests join while in lobby.
-
Interesting. The last time I ran into an OutOfMemoryError this was due to a (by myself) poorly implemented breadth-first-search.
Might be worth to look at the code to check if some uneccessary object creations can be avoided. -
@roiex Yeah, I have a feeling we have a memory leak somewhere. My gut says its something to do with the battle calc as I've noticed my memory going up over time if I play a long session on a complex map. It seems to be true for the AI which uses the calc as well.
@Ayoross An interesting test would be trying the Fast AI instead of Hard AI as the main difference between them is the Fast AI doesn't use the battle calc.
-
I don't think there's a leak, I didn't see the tenured space usage growing endlessly in a 2-hours long game.
However it would be a good idea to decrease the memory footprint of the hard AI.
Concerning the fast AI, as far as I know (few tests), there's no issue with a 1 GB heap, but the creator of GW recommends the use of the hard AI.
Note also that a more simple map would probably require less resources, all my testing was based on GW.
-
I recall @LaFayette submitted a PR which reworked a lot of the OddsCalculator code, but the changes got reverted, because of unintentional uneccessary network usage, that slowed down the OddsCalculator by a lot when playing a networked game.
Might be worth to revisit that. -
-
... only if I could find the corresponding jar file. I have no java dev environment
-
@ayoross I'm guessing @RoiEX comment was meant for me but you can find all releases here: https://github.com/triplea-game/triplea/releases
-
@redrum My comment was for everybody interested ^^
Found a release with this change: https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.7395@Ayoross Regarding CMS. Keep in mind that CMS is considered to be deprecated as of Java 9 per JEP 291, it will still work, but warn users when invoked from the command line.
-
I think CMS is widely used and will still work some more time. Anyway, G1 is supposed to replace it sooner or later but the "battle calculator" creates huge objects, causing humongous allocations, which can be quite harmful. I tried with 6 MB regions, they still happen. All java apps using large objects are not good candidates for G1 migration, especially when the CMS works fine. I have the same problem using apache jmeter on HTTP content. That's only my opinion, of course.
Note also this :
"This JEP does not specify the major release in which support for CMS will be dropped. The decision of when to do that will be informed by the extent to which the G1 collector proves to be a suitable replacement for CMS. In the meantime, CMS users are encouraged to migrate to the G1 collector (-XX:+UseG1GC)" -
@ayoross I agree.
You might want to point out people might experience issues in the future or see a scary warning when launching from the command line (not sure when this warning is logged, or if JVM warnings are being swallowed) -
Hi,
I tried the 1.9.0.0.7395 release, unfortunately the game crashes after 1 or 2 minutes on a functional error like "Possible Infinite Loop: Wrong number of casualties selected: ...".
I does not work long enough to be sure, but it still looked like the memory usage was significantly smaller. You should perhaps consider reusing this code after some cleanup.
With this code, the G1 collector should probably work fine ^^
-
@ayoross Well I opened a PR a day ago that tries to cleanup the code: https://github.com/triplea-game/triplea/pull/2950
However we're running into the exact same issue you just described. (By we I mean @ssoloff and myself.)
We're currently assuming it has something to do with concurrency issues.
However in case we get everything working it does currently not look like the memory footprint is going down.
Looks like this requires much more changes than a small algorithm
closed Parallel OddsCalculator #2950
