Unpopular opinion, but I believe that all this crashing is likely caused by Java tweaks.
As is often the case, these really long java-tweak copy/pastes often do not have practical performance increases, but defeinitely can put java in a state of unpredictable usage and throughput.
Are you familiar with the default distributed garbage collector for RMI?
Notable problems related to this tweak: “You observe a pattern of explicit garbage collection on a regular interval (usually every 60 seconds), but the application does not contain any System.gc() calls. The problem might be Remote Method Invocation (RMI) distributed garbage collection.”
The amount of time a garbage collector can schedule compute time before surrendering it back to other processes.
If a Garbage collection cannot complete in 50 milliseconds, it will stop, making comparatively inefficient use of its time. Incomplete garbage collections will result in a need for the garbage collection to run again, sooner than expected, because it didn’t clear as much in the 50 millisecond allotment it previously had. To put it in perspective, it used to be 200ms.
Realistically, think of this like cleaning your kitchen, instead of a lot at once (like before, after), but by doing it every 5 minutes, for 30 seconds. There’s so much overhead in switching your mode from “operating mode” to “cleaning mode” that there is a needless increase in overhead and context switching.
This makes the G1 collector’s size of the young generation, set as a percentage of the heap.
You’re making the young generation size 20%, which in itself isn’t bad (compared to the 5% default), but you make the heap 4 times larger and you gave the time to garbage clean it 1 quarter the time it previously had.
Realistically, you’re telling the G1 collector to work 16 times more efficiently (if it were to complete GCs), which I don’t think it is pulling off.
Purpose: “Sets the percentage of reserve memory to keep free so as to reduce the risk of to-space overflows. The default is 10 percent. When you increase or decrease the percentage, make sure to adjust the total Java heap by the same amount.”
That is, you’re setting the memory reserve (read as "memory that can’t be used by minecraft) to be twice as large). "to-space is used during GCs to help determine proper file tenuring.
Put these all together:
- We’re making the young generation of the heap bigger.
- We’re giving it less time to go through it
- We’re giving minecraft less space by reserving more of the heap for garbage collection overhead.
- We’re using experimental options and having unexpected behavior.