Minecraft only uses however much memory it needs; I have absolutely no idea why so many people think that a program MUST use as much memory as possible when it should be the opposite (memory is extremely slow when compared to the speed of a CPU, which only have a few MB of high-speed cache memory); in fact, you can see here that allocating more memory degrades performance and here (from Oracle themselves) that 64 bit is actually often slower than 32 bit due to the increased amount of memory it needs (especially for a program like Minecraft 1.8+, which allocates objects like crazy. This is also why even 64 bit programs usually use 32 bit ints as a general purpose integer data type).
Not to mention, swap "memory" is even slower - literally thousands to millions of times - even if you have a SSD (and a USB drive does not come even close to an internal drive) - and you absolutely NEVER want to use it!
Plus, the game does not require that much memory; the default allocation of 1 GB is there for a reason and should only be increased if you want to use high render distance, mods (which are awfully coded along with Forge itself; my own non-Forge modded version only needs 100 MB and I can't even begin imagining the allocations that others use given that I can't even allocate more than 1 GB on a 32 bit system, which has never given me any trouble). You also need to account for JVM overhead and memory used by the OS and other programs:
Let's give Minecraft 4 GB of RAM to play with. This would need a PC with at least 8 GB RAM (as the real memory usage is almost double the memory visible in Java). If the VM decides to use all the memory, then it will increase the time between the garbage collections (20 sec instead of 4), but it will also increase the garbage collection time by 4, so every 20 seconds there will be one massive lag spike.
-and-modding-java-edition/minecraft-mods/1272953-optifine-hd-d2-fps-boost-dynamic-lights-shaders?page=2090#c43757
So you should not allocate more than 8 GB on a 16 GB system, and ideally based on the actual amount of free memory that you have (JVM overhead may be less for higher heap sizes as it likely does not scale up).
In addition, incremental CMS is deprecated (obsolete in Java 9+) and should not be used unless you happen to have a single-core CPU, which it was designed for (any modern CPU should have enough cores/threads to run the garbage collector in a truly concurrent manner):
The latest version of the launcher by default enables incremental garbage collection (-XX:+CMSIncrementalMode) which in theory should replace the one big GC with many shorter incremental GCs. However the problem is that the time at which the smaller GCs happen and their duration are mostly random. Also they are not much shorter (maybe 50%) than a full scale GC. That means that the FPS starts to fluctuate up and down and there are a lot of random lag spikes. The stable FPS with a lag spike from time to time is replaced with unstable FPS and microstutter (or not very micro depending on the CPU). This strategy can only work with a powerful enough CPU so that the random lag spikes become small enough not to be noticeable.
(NB: this is now outdated - they removed it from the default arguments due to the fact that Java 9+ won't even run if you try to use it)
This feature is useful when applications that need the low pause times provided by the CMS collector are run on machines with small numbers of processors (for example, 1 or 2).