- Sep 8, 2019
- 532
- 909
In all fairness, a lot of that seems more likely to be tied into the way the JRE handles memory allocations. I don't have a huge amount of experience with it, but from what I've seen over the years it seems to have more of a tendency to exhaust its heap before garbage collecting, whereas .NET's GC fires off more often and keeps the process's memory allocation more stable. This makes sense, as the JRE is all about limiting the heap size to a particular block on startup, while the only limit to the CLR's available heap size is the maximum process size (2GB on x86, effectively unlimited on x64).My last play through where I actually let myself engage with the sim side of things was using 3gb of memory within like 20 in-game days.
I use a number of Java-based tools (I use the JetBrains IDEs extensively, used to use dbeaver/SoapUI, and had the "pleasure" of administering self-contained JIRA and Bitbucket Server instances), as well as play unhealthy amounts of Minecraft when the mood strikes, and they all seem to follow the trend of allocating as much memory as they can before doing something about it.
That's not to say that LT is perfect at managing memory, because it definitely isn't. LT slings around temporary collections like they're going out of style, so it's no wonder it fills up the heap quickly. I suspect that the performance improvements for most systems are more likely to involve simply allowing the JRE to call the GC less often. If LT were truly filling the heap and running the JRE out of memory, the application would be unceremoniously killed with an OutOfMemoryError exception. I haven't run into that even during my most brutal stress testing.
At some point I'd like to do some more in-depth heap analysis to see what's really going on. I'm currently stuck without my Linux dev box, and that might be a fun first project for its replacement.
Edit: It's worth reiterating that this is purely anecdotal, and that I have far more practical/technical experience with .NET. I did try to look up some information, but the history of Java's garbage collector is a bit muddied by the fact that different JREs can have different GC strategies, and that LT is still using Java 8 (no thanks to Oracle still recommending it for general use).
Last edited: