When you control the memory allocation for Minecraft, you really only are configuring the JVM's garbage collector to use that much memory. That doesn't include any shared resources outside of the JVM, such as Java itself, OpenGL resources and everywhere else that involves native code and system libraries and drivers.

If you have an integrated GPU, all the textures that normally gets sent to a GPU may also live on your regular RAM too since those use unified memory. That can inflate the amount of memory Java appears to use.

A browser for example, might not have a whole lot of JavaScript memory used, couple MBs maybe. But the tab itself uses a ton more because of the renderer and assets and CSS effects.

This is normal behavior. There is much more to the JVMs memory usage beyond what's allocated to the heap - there are other memory regions as well. There are additional tuning options for them, but it's a complicated subject and if you aren't actually encountering out of memory issues you have to ask if this is worth the effort to tune it.

Depending on version and if modded with content mods, you can easily expect Minecraft to utilize a significant portion memory more than what you give for its heap. Java processes have a statically / dynamically (with bounds) allocated heap from system memory as well as memory used in the stack of the process. Additionally Minecraft might show using more memory in some process monitors due to any external shared libraries being utilized by the application.

My recommendation: don't allocate more memory to the game than you need to run it without noticeable stutters from garbage collection. If you are running modded Minecraft, one or more mods might be causing stack-related memory leaks (or just being large and complex enough to genuinely require large amounts of memory. We might be able to get a better picture if you shared your launch arguments, game version, total system memory, memory used by the game in the process monitor you are using (and modlist if applicable).

In general, it's also a good idea to setup and enable ZRAM and disable Swap if in use.

As a side note and a little psa, if you need to squeeze out more overall performance of out of MC (and you are playing vanilla or Fabric modpack) I very much recommend using these Fabric mods: Sodium, Lithium, FerriteCore and optionally Krypton (server-only), LazyDFU, Entity Culling, ImmediatelyFast.

I'm sorry but I think that's just the way Java Edition goes mate, lol.
You see a modpack that recommends 6GB allocated and you think "oh, I'm fine, I have 16", next thing you know you're almost going OOM.

I have recently upgraded to 32GB solely because of 'All The Mods 9'

Modded Minecraft is memory hungry. Even normal Minecraft can be. I've seen people suggest alternative JVMs (open j9) because they supposedly garbage collect more aggressively before requesting more memory. I tried this once with Forge back when it had to patch everything when it began (maybe still the case, idk) and what it actually did was just make everything slow to a crawl because the JVM wanted to collect instead of allocate more and keep going.

File bug reports with mid authors and Mojang of it is using way more memory than they say it needs so they update their docs but this is pretty much par for the course.

Think about it like this. You have a table. You have papers. You're doing complicated math. You can use more and more of the table for scratch work on your papers. At some point you run out of table space. You consolidate the papers and notes you've taken on them. But that's time you could've been doing more "useful" work. Now, what if you had like 90% of the table still full once you did that? You'd honestly need more table.

Minecraft is a great game, but when you push it to the extremes it has difficulty keeping up.

https://stackoverflow.com/questions/1493913/how-to-set-the-maximum-memory-usage-for-jvm

I would be more concerned about qbittorrent casually eating 11.1 gigs of ram

glibc's malloc increases the stacksize of threads depending on the number of cpu cores you have. The JVM might spawn a shitload of threads. That can increase the memory usage outside of the JVMs heap considerably. You could try to run the jvm with tcmalloc (which will replace malloc calls for the spawned process). Also different JVMs bundle different memory allocators. I think Zulu could also improve the situation out of the box. tcmalloc might still help additionally.

Minetest.net