The extra cores don't necessarily affect MC itself, but they do help with the GC and compiler.
Actually, the compiler is a big thing. You could, for example, add in flags to force a lot of extra compilation and data flow analysis, and there's CPU to spare.
It's not clear that explicitly indicating tenuring threshold max does anything. The JVM dynamically adjust this value to promote to tenured.
This one I can tell you. Minecraft's memory allocation can vary significantly. The JVM wants to have tenuring threshold as high as possible. This means that all of a sudden, very large amounts of memory can be tenured at once -- everything from generation 2 to generation 15.
This will confuse the CMS collector -- it doesn't start a collection soon enough. It doesn't cause concurrent failure, but it does trigger "I need to allocate more memory".
This in turn will cause problems on smaller machines. Not so much if you have a 16 GB machine only running minecraft. But if you have a 4 GB machine, with a client, a server, a voice chat, a screen recorder, etc., then I really needed to keep minecraft from unnecessarily expanding it's memory allocation. I needed to know that it _could_ allocate more if it had to, but would not do so "just because".
So I learned. Experimental behavior -- the system worked better if the combination of:
Tenuring threshold
Survivor space
Eden space
were such that objects would expect to last at least 30 seconds before leaving survivor into tenuring.
This meant that the size of eden (determines the frequency of minor collections), times the copy threshold, was at least 30 seconds. Holding stuff in survivor longer did NOT help reduce tenuring enough to be worth the extra memory allocation.
Additionally, when moving from point A to point B, and loading chunks, then stuff would tenure faster. Unavoidable. But I could make sure that the size was enough that it never overflowed survivor -- letting survivor fill up to the point that any surviving object must be copied into tenured space even if it's a short-term temporary is a disaster in CMS -- even when moving through an extreme hill, or a cave world/nether.
What I learned, and this will be modpack dependent, is roughly this:
1. If you have a good handle on new (eden+survivor), and the minfree/maxfree settings (hint: Java's defaults for free space are way too high, something like 50% free, it can be happy with about 20-25%), then tenured will not grow excessively.
2. You can monitor the program/modpack, and determine what you need for survivor (how much stuff will survive for 30 seconds)
3. By raising eden as large as you can afford, for that given level of tenured plus survivor, you can determine how big to make new -- and then give it a little bit more just-in-case
4. And this will minimize the total memory used by Java, and the best "system friendly" behavior.
Why use CMSInitiatingOccupancyFraction? 80% is default and its not clear that starting collection earlier will improve performance
My thinking on this one isn't quite the same as Eyamaz's. I don't use occupancy fraction only. I let Java adjust it's timing on this.
What I do pay attention to is minfree. If I have minfree of 15, and occupancy of 80, then it will do constant minor collections; if I have minfree of 22, and occupancy of 80, then it will expand memory allocation. I'm still trying to figure out how to say "Don't over allocate, but don't over run the collector".
The rest of the flags that Eyamaz uses I can't comment on. Eya has been working with J7 longer than I have -- I was on J6 until recently.[DOUBLEPOST=1392863763][/DOUBLEPOST]
What about anything for small, poor 32 bit systems? Currently I'm only using the ConcMarkSweepGC, and that's because I randomly found out about it while googling, but even that alone has been helping with the memory usage, especially when I go to different dimensions. As for the RAM allocation, it's set to 512M min, 812M max, 96M permgen because it's really that poor. Still manages to run a small pack with 68 mods in the folder and 107 in the title screen just well enough.
Yeah yeah I know I should upgrade my computer and all that but that's not an option at the moment, so I'd like to try getting the best of what I have right now.
Poor? Ha.
32 bit J6 performed better than 64bit J6.
J7 on the mac only comes in 64 bit.
32 bit systems have smaller data structures and overhead. They are actually able to run in smaller space.
For my modpack, I think I needed 200 MB for tenured, 120 MB for new (ratio of 1), so that was set at 350 MB to start, 550MB max, and it ran nicely. That was for the server -- client needed different figures (bigger new, bigger max) and had additional graphics overhead.
