With the GC and total memory use, This is how Java works - I doubt there is any issue with the launcher, unless I'm missing another detail. The JVM will only do garbage collection when necessary (or when it thinks it's a good time). And the fact the GC brings down the used heap means that none of that was in use anymore (ie. not leaking).
On your computer, it appears your JVM is launching with 1.7GB heap allocated and a max heap of 4GB! The JVM has no real reason to do GC when it has so much memory to use. Maybe it even started off with a smaller heap, but just decided to increase the size because of the massive max size. I'd guess the JVM is simply not going to waste CPU cycles to keep the free heap size at >90%/1.5GB when there is no reason to. It does take CPU time for the JVM to calculate which objects are no longer reachable - the less GC cycles, the less CPU time needed.
On the note of it slowly climbing, I wouldn't be surprised - For instance if it is keeping a connection open, then any flowing packets have to go into memory somewhere (such as byte[]). In fact, using JVisualVM, I see it has some TCP connections open. The big one that sticks out to me is that the News page appears to a Tumbler page - guessing it's this guy: http://mcupdate.tumblr.com/. I can't say for sure if the MC launcher's widget runs JavaScript, but I see JavaScript in there, and using the JavaScript profiler in the developer tools in Chrome, I see that JS engine running for the page will occasionally use CPU time (a small amount) and even has its own GC is running, meaning it is allocating objects too. Maybe it leaves open a connection in case the page is updated? Don't really know for sure.
My main point is that the launcher is doing stuff behind the scenes, so inevitably it is creating objects and destroying them. It's up to the GC when to get rid of them for good. If the GC isn't running, it's because the JVM doesn't think it needs to. When the GC fails to recover the memory back down to a reasonable amount, then you may have a problem (ie. leaking).
On my computer (Windows, Oracle Java 1.7.0_21 x64, I wouldn't imagine that would change a whole lot, could be wrong - I still see the slow constant object allocation), the launcher has a max heap size of like 135MB, and a size of about 100MB. The used size bounces between about 50-70MB (slowly). Forcing GC causes the used heap to always go back down to around 20M. Looking at the JVM arguments for the launcher (reported by JVisualVM), it says -Xmx:128m. Looks like my JVM is sticking to around the max heap size it was told. Everything is the way I would expect at least. I wonder if your JVM/launcher settings were tweaked to allow the launcher to have a max of 4G? I'm sure if I gave it 4G, it would happily use it all too! 😃
Trevor Thune
This is a bit verbose, but I hope it is helpful.
With the GC and total memory use, This is how Java works - I doubt there is any issue with the launcher, unless I'm missing another detail. The JVM will only do garbage collection when necessary (or when it thinks it's a good time). And the fact the GC brings down the used heap means that none of that was in use anymore (ie. not leaking).
On your computer, it appears your JVM is launching with 1.7GB heap allocated and a max heap of 4GB! The JVM has no real reason to do GC when it has so much memory to use. Maybe it even started off with a smaller heap, but just decided to increase the size because of the massive max size. I'd guess the JVM is simply not going to waste CPU cycles to keep the free heap size at >90%/1.5GB when there is no reason to. It does take CPU time for the JVM to calculate which objects are no longer reachable - the less GC cycles, the less CPU time needed.
On the note of it slowly climbing, I wouldn't be surprised - For instance if it is keeping a connection open, then any flowing packets have to go into memory somewhere (such as byte[]). In fact, using JVisualVM, I see it has some TCP connections open. The big one that sticks out to me is that the News page appears to a Tumbler page - guessing it's this guy: http://mcupdate.tumblr.com/. I can't say for sure if the MC launcher's widget runs JavaScript, but I see JavaScript in there, and using the JavaScript profiler in the developer tools in Chrome, I see that JS engine running for the page will occasionally use CPU time (a small amount) and even has its own GC is running, meaning it is allocating objects too. Maybe it leaves open a connection in case the page is updated? Don't really know for sure.
My main point is that the launcher is doing stuff behind the scenes, so inevitably it is creating objects and destroying them. It's up to the GC when to get rid of them for good. If the GC isn't running, it's because the JVM doesn't think it needs to. When the GC fails to recover the memory back down to a reasonable amount, then you may have a problem (ie. leaking).
On my computer (Windows, Oracle Java 1.7.0_21 x64, I wouldn't imagine that would change a whole lot, could be wrong - I still see the slow constant object allocation), the launcher has a max heap size of like 135MB, and a size of about 100MB. The used size bounces between about 50-70MB (slowly). Forcing GC causes the used heap to always go back down to around 20M. Looking at the JVM arguments for the launcher (reported by JVisualVM), it says -Xmx:128m. Looks like my JVM is sticking to around the max heap size it was told. Everything is the way I would expect at least. I wonder if your JVM/launcher settings were tweaked to allow the launcher to have a max of 4G? I'm sure if I gave it 4G, it would happily use it all too! 😃