Minecraft ships with 64-bit Java AND with 32-bit Java, and Java is smart enough to pick 64-bit over 32-bit when available. The 32-bit issue would only come into play if you only had 32-bit hardware/32-bit OS OR were using another piece of software that didn't come bundled with both 64-bit and 32-bit java (usually modded clients and external utilities like Admidst, I think).
The game only uses as much memory as it needs, so if it only needs 500 MB it will only use that much, regardless of whether you allocate 512 MB or 512 GB (though the JVM will reserve all of that memory, making it unusable for anything else) - I have no idea where the idea ever came from but everybody seems to think that the game MUST use as much memory as possible in order to reach maximum performance - memory doesn't work like that. If anything, more memory slows things down; everything being equal, and running on a matching OS, 32 bit Java is generally faster than 64 bit (32 bit runs worse on a 64 bit OS since the OS has to emulate a 32 bit environment) because it uses less memory:
Generally, the benefits of being able to address larger amounts of memory come with a small performance loss in 64-bit VMs versus running the same application on a 32-bit VM. This is due to the fact that every native pointer in the system takes up 8 bytes instead of 4. The loading of this extra data has an impact on memory usage which translates to slightly slower execution depending on how many pointers get loaded during the execution of your Java program.
The default heap size for all 32-bit J2SE implementations is 64MB. We have adjusted the defaults for 64-bit implementations to be 30% larger in order to make up for the increased size of Java objects due to larger native pointers. Remember that Java objects contain class and lock pointers so even if you create Java objects which contain only integers, each object takes up additional memory.
(modern Minecraft is extremely heavy on pointer usage because since 1.8 Mojang has gotten it into their minds that everything, even things as basic as block coordinates, need to be separate objects, with upwards of 200 MB of new objects allocated per second, and this is why the system requirements have risen so much since then, not because of new content)
As for GPU usage not hitting 100%, that is because something else, likely the CPU, is preventing it from being fully utilized - CPU utilization will also never reach 100% (unless you have an ancient single-core CPU, maybe also dual-core) since much of the game runs on a couple threads (one for the client/rendering and another for the internal server/game logic).
Garbage collectors work like that. Their efficiency is proportional to the amount of memory you are wasting, if you consider the ratio garbage_found/objects_traced. Generational collectors can improve the ratio, but the basic relationship is still there.
If that is the case then why doesn't the JVM always allocate as much memory as possible?
Apparently, it thinks that it needs only 22% of the maximum allowed and a bit over twice the used memory (I took this screenshot at a minimum in memory usage after generating a new world and letting it stabilize so this mainly reflects what the game actually needs, and even then the GC likely didn't free every bit of memory). Even after flying around or traveling by minecart for thousands of blocks or playing for hours it typically uses no more than 300-350 MB (moving around increases the rate of memory allocation, which otherwise tends to rise until it reaches a steady state after some time). There is also no difference when I allocate 512 MB (as I normally do; I took the above in MCP, which allocates 1 GB) and I'm sure that even 256 MB would be the same (the GC might run a bit more often by the time it would exceed 256 MB but I doubt it would be noticeable since it clearly has enough space; traveling to another dimension may cause issues since the game temporarily loads two worlds in memory. Also, memory usage in the example above actually decreased within the first couple minutes, as objects created during world creation were cleaned and allocation rates dropped as chunk updates did).
Because you might be running other programs on your computer. If you give it 8GB and it lets 7.7GB of garbage pile up before collecting, that's 7.7GB that other programs can't use, and that may cause page swapping or even an out of memory error.
That is not the case though since I have over 1 GB free while playing, and even with just 512 MB allocated it never reaches 100%, plus I don't think the JVM actually looks at free system memory except when you initially allocate it (hence why I get "unable to create Java virtual machine" if I allocate much more than 1 GB, the limit for a 32 bit OS - even if it doesn't actually allocate that much right away) and I've never gotten a low memory warning from Windows. I've also made the game allocate all 1 GB with no issues by changing the radius of the initial spawn area to 50 chunks instead of 12 to force the game to generate terrain for testing (actual used memory is 600-700 MB; performance is not noticeably different despite 100% of memory being allocated and the rise/fall of memory above the minimum is about the same as normal).
Maybe your observations are the result of the JVM arguments that you use; I use the following (MCP just uses -Xincgc -Xmx1G, with -Xss1024K added in both cases to prevent issues with stack overflow due to water/lava during world generation)
(and, of course, versions since 1.8 are terribly optimized, allocating objects like there is no tomorrow; "The 200 MB/sec is pushing the limits and forcing the garbage collector to do a lot of work which takes time")
Set the desired level of memory in the Launcher. The game does not rise above 500 MB of memory usage. Please fix this memory limit.
GPU usage in game in java version is not 99%.
Maximum performance from Nvidia or AMD chose Although the interface is selected.
You're looking at RAM and GPU use not being capped, and wondering why you can't force these uses higher to speed the game's performance up, when this is not how it works.
RAM is just something a program needs enough of to run in a given instance and this is it; throwing more at it won't do anything. GPU is generally the limiting factor in most other games but not Minecraft. Minecraft is especially CPU limited, and if any sort of "proper" GPU is in place (such as in a so-called "gaming" PC), then this is even more likely. From my understanding, modern Minecraft (namely, since after 1.7 or 1.8 especially) is just terribly optimized due to the way it has decided to handle redesigning how the game operates. Some of this (from my limited understanding) seems to pertain to the garbage collector (which clears memory), but this doesn't mean the problem is lack of memory itself. It's way, way, way more down to the CPU just not being able to keep up, and since CPU's IPC and clock speed has been slowing more and more over the years (my ancient Core i5 2500K is still very relevant today, for example), Mojang is taking a very reckless approach with this I think.
Please Fix the 1.13.1 FPS drop problem.
Set the desired level of memory in the Launcher. The game does not rise above 500 MB of memory usage. Please fix this memory limit.
GPU usage in game in java version is not 99%.
Maximum performance from Nvidia or AMD chose Although the interface is selected.
I gave the game 4 GB of memory nearby.
Minecraft ships with 64-bit Java AND with 32-bit Java, and Java is smart enough to pick 64-bit over 32-bit when available. The 32-bit issue would only come into play if you only had 32-bit hardware/32-bit OS OR were using another piece of software that didn't come bundled with both 64-bit and 32-bit java (usually modded clients and external utilities like Admidst, I think).
The game only uses as much memory as it needs, so if it only needs 500 MB it will only use that much, regardless of whether you allocate 512 MB or 512 GB (though the JVM will reserve all of that memory, making it unusable for anything else) - I have no idea where the idea ever came from but everybody seems to think that the game MUST use as much memory as possible in order to reach maximum performance - memory doesn't work like that. If anything, more memory slows things down; everything being equal, and running on a matching OS, 32 bit Java is generally faster than 64 bit (32 bit runs worse on a 64 bit OS since the OS has to emulate a 32 bit environment) because it uses less memory:
(modern Minecraft is extremely heavy on pointer usage because since 1.8 Mojang has gotten it into their minds that everything, even things as basic as block coordinates, need to be separate objects, with upwards of 200 MB of new objects allocated per second, and this is why the system requirements have risen so much since then, not because of new content)
As for GPU usage not hitting 100%, that is because something else, likely the CPU, is preventing it from being fully utilized - CPU utilization will also never reach 100% (unless you have an ancient single-core CPU, maybe also dual-core) since much of the game runs on a couple threads (one for the client/rendering and another for the internal server/game logic).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
If that is the case then why doesn't the JVM always allocate as much memory as possible?
Apparently, it thinks that it needs only 22% of the maximum allowed and a bit over twice the used memory (I took this screenshot at a minimum in memory usage after generating a new world and letting it stabilize so this mainly reflects what the game actually needs, and even then the GC likely didn't free every bit of memory). Even after flying around or traveling by minecart for thousands of blocks or playing for hours it typically uses no more than 300-350 MB (moving around increases the rate of memory allocation, which otherwise tends to rise until it reaches a steady state after some time). There is also no difference when I allocate 512 MB (as I normally do; I took the above in MCP, which allocates 1 GB) and I'm sure that even 256 MB would be the same (the GC might run a bit more often by the time it would exceed 256 MB but I doubt it would be noticeable since it clearly has enough space; traveling to another dimension may cause issues since the game temporarily loads two worlds in memory. Also, memory usage in the example above actually decreased within the first couple minutes, as objects created during world creation were cleaned and allocation rates dropped as chunk updates did).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
That is not the case though since I have over 1 GB free while playing, and even with just 512 MB allocated it never reaches 100%, plus I don't think the JVM actually looks at free system memory except when you initially allocate it (hence why I get "unable to create Java virtual machine" if I allocate much more than 1 GB, the limit for a 32 bit OS - even if it doesn't actually allocate that much right away) and I've never gotten a low memory warning from Windows. I've also made the game allocate all 1 GB with no issues by changing the radius of the initial spawn area to 50 chunks instead of 12 to force the game to generate terrain for testing (actual used memory is 600-700 MB; performance is not noticeably different despite 100% of memory being allocated and the rise/fall of memory above the minimum is about the same as normal).
Maybe your observations are the result of the JVM arguments that you use; I use the following (MCP just uses -Xincgc -Xmx1G, with -Xss1024K added in both cases to prevent issues with stack overflow due to water/lava during world generation)
-Xmx512M -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy -Xmn128M -Xss1024K
(and, of course, versions since 1.8 are terribly optimized, allocating objects like there is no tomorrow; "The 200 MB/sec is pushing the limits and forcing the garbage collector to do a lot of work which takes time")
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
You're looking at RAM and GPU use not being capped, and wondering why you can't force these uses higher to speed the game's performance up, when this is not how it works.
RAM is just something a program needs enough of to run in a given instance and this is it; throwing more at it won't do anything. GPU is generally the limiting factor in most other games but not Minecraft. Minecraft is especially CPU limited, and if any sort of "proper" GPU is in place (such as in a so-called "gaming" PC), then this is even more likely. From my understanding, modern Minecraft (namely, since after 1.7 or 1.8 especially) is just terribly optimized due to the way it has decided to handle redesigning how the game operates. Some of this (from my limited understanding) seems to pertain to the garbage collector (which clears memory), but this doesn't mean the problem is lack of memory itself. It's way, way, way more down to the CPU just not being able to keep up, and since CPU's IPC and clock speed has been slowing more and more over the years (my ancient Core i5 2500K is still very relevant today, for example), Mojang is taking a very reckless approach with this I think.
1.13.1 fixed ur fps