The bug

Game stutters badly if the non-default arguments "-Xmx2G -Xmn2G" are passed to the JVM, but this just makes an existing problem more apparent: MC relies on automatic GC within Java, and does not initiate GC under app control.

The reason

Automatic GC in Java is optimized for maximum performance in benchmarks more than anything else, and not for real-time applications. In fact, it might not even be coalescing free blocks (which might or might not matter to MC). This means that if the current memory pool has somehow become too large (either due to "-Xmn" or just vagaries of Java implementations), the automatic mark/sweep GC can take so long as to cause noticeable pauses in the client.

Suggested fix

Create a GC thread within the MC client, that maintains a running estimate A of the actual referenced memory (the memory that would be remain allocated to the app after a GC completes), and periodically (e.g. every second) compares the currently-used memory B with A: if the ratio of B to A exceeds a certain fixed value (e.g. 1.5), a Major GC is explicitly initiated by the thread.