Vanilla Launcher eats memory. The linked images are with the launcher sitting at the login screen. It slowly eats memory until it hits over a gig when a GC occurs and it falls back down and repeats repeatedly. The max memory that it eventually settled at having allocated on my system was ~1.7gigs and after a GC event it was only using ~290megs of the allocated 1.7gigs that it was not releasing to the system.
The largest sizable growth appeared the be the int[] primitive arrays, however the char[] primitive arrays were fairly large as well while also growing at a fairly decent rate. Everything else seemed to be fairly ignorable in both growth rate and memory usage eating a combined total of less then 150megs.
Example of climbing memory usage with a forced GC from jVisualVM: VanillaLauncherAtLoginScreen1.png
#1 and #2 memory usage in jVisualVM: VanillaLauncherAtLoginScreen2.png
This is while using Oracles recently released Java8. Have not tested on Java7.
Attachments
Comments 17
The launcher actually does more than you think. 🙂 Also there are constant changes to the launcher, remember it hasn't been around as long as MC. They are frequently doing more and more with it, but in small increments. Every time you open your launcher it could be a new version, with something changed. Usually small tweaks here and there enabling more features for the base game, along with the coming API and these tweaks have to be included then refined. Which is where bug reports come in handy. I've seen various parts of MC grow and shrink, consider the recent snapshot AI change over to the same as the Zombie AI, yay can throw out the old stuff! But the Zombie AI was in there since... 1.6.2 I believe.
Personally I recommend closing the launcher when you run the game, it usually doesn't need to be running and frees up that much more RAM.
Sadly I cannot be more specific, that's up to Mojang not me. Patience will show you why it has anything to do with it.
@Torabi Except that it was not with the game running, it was just sitting at the launchers login screen. More research shows that it is likely caused by vast inefficiencies in swing, which should really be dropped for JavaFX or so...
Presumably because they got tired of telling people to ignore it because it wasn't implemented yet, and therefore didn't work properly.
Java 7 x64 on Windows shows a negligible climb, and even your own graph shows Java GC keeping it in check. So unless this is worse on *nix the impact is minimal and they are more likely to put time into the client RAM usage than the launcher.