[MC-62817] Lag over time, possibly memory leak

After several hours the game becomes less responsive(player movement gets choppy) and uses more memory. FPS seems unaffected and cpu usage never exceeds 35%. As I catch up on the changes in minecraft over the last few years I'm often running tests on mechanics in the background while sleeping or afk. In 1.7.9 and 1.7.10 and even 14w28b this never caused me issue. Even though I've allowed for up to 4gb of memory to be allocated the previous versions never exceeded 2gb allocated. In 14w29b, however, I have noticed that the overall memory usage will have doubled to tap at the 4gb consistently in about 8 hours time. Even if nothing of consequence is occurring in the world(which was last nights test). This may also be related to the visits from Herobrine(which causes an immediate jump in memory usage). However I'm leaning more towards memory leak. Oh, and this is in single player.

Update: the following Java 8 Arguments fixed this for me,

-Xmx1G -Xmn128M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-UseAdaptiveSizePolicy

Attachments

crash-2014-07-22_05.35.44-client.txt

crash-2014-07-22_06.01.20-client.txt

crash-2014-07-29_10.16.39-client.txt

Comments 28

kumasasa 2014-07-21T21:14:46Z

Please force a crash by pressing F3 + C for 10 seconds while in-game and attach the crash report ([minecraft/crash-reports/crash-<DATE>-client.txt|http://hopper.minecraft.net/help/finding-minecraft-data-folder]) here.

Someone 3x7 2014-07-22T12:49:03Z

For whatever reason it wasn't quite as bad this morning. Maybe herobrine didn't stop by for a visit last night. Still some stutter in the movement, however, not nearly as bad. Plus memory usage was much lower than previous mornings. Although, still about 20% more memory actively being used than I am used to seeing. I'll keep tinkering around and see if I can't figure out the difference and get you a better report. In the mean time I'll upload this one.

Someone 3x7 2014-07-22T13:04:14Z

For comparison this second crash report is what it is like when I first load the world.

Someone 3x7 2014-07-22T14:40:56Z

One thing I have been playing with in the current snapshot that I've not before is the villager farming. After checking the world I ran last night over head to toe I found about 12 of 24 farmers I set up had gone inactive. They ran out of crops to plant at some point. It may be coincidental, yet, it is the only difference I can find between last night and previous nights.

kumasasa 2014-07-22T19:51:56Z

You're using a lot of non standard JVM options:

-Xms2G -Xmx4G -XX:ParallelGCThreads=4 -XX:+UseG1GC -XX:MaxGCPauseMillis=500

How much RAM does you computer have ?
If you answer something less than 8 GB then reduce the Xmx.

You might remove the -XX one after each other and see if this has any impact on the lag.

Additionally you might upgrade to Java 8U11: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

18 more comments

Someone 3x7 2014-07-23T15:47:04Z

My machine specs are already listed in the environment section. However, to answer again I've exactly 8gb.

I will try removing the non-standard options one at a time, however, it should make little difference. I was running similar tests on a much more massive scale in 1.7.9 and 1.7.10 under the same jvm version and options without experiencing this type of issue.

Concerning upgrading to a Java pre-release am I to assume Minecraft 1.8 is being developed for that version of java? If so I'll try it, otherwise I'm a bit leery of beta testing for Oracle too.

Someone 3x7 2014-07-24T14:27:46Z

This appears to be resolved in 14w30b without making any additional changes to my settings or setup. I'll let you know if it crops up again.

kumasasa 2014-07-24T20:19:00Z

Ok, please comment if it comes back.

Anonymous User 2014-07-28T23:53:50Z

YOU DO NOT NEED 4GB. You only need 350mb.

kumasasa 2014-07-29T02:53:46Z

@unknown

YOU DO NOT NEED 4GB. You only need 350mb.

Err, what ?

Someone 3x7 2014-07-29T17:11:59Z

My thoughts exactly. This issue cropped up again while I was doing some additional testing on another issue. After disabling all the non-standard java options it actually happened in a matter of minutes instead of hours(Seems I had optimized it for a reason... .. .). So I came back here to get that link for java 8 and found trolls were added to Minecraft.

Someone 3x7 2014-07-29T17:19:35Z

This latest crash report using Java 8 update 11 was after less than a minute.

Edit: Oh, and there are no villagers in this world. Although, the report should say that too.

Someone 3x7 2014-07-29T17:37:57Z

Something else I noticed once before and just again now, is that rain seems to temporarily correct this issue. The overall memory usage nearly halves when it starts raining and movement gets quite smooth.

Someone 3x7 2014-07-29T17:58:55Z

I hate to spam comments like this, but, I also just noticed that some aspects of the game do run much smoother in Java 8 without the non-standard options. Namely water and lava flow much faster.

kumasasa 2014-07-29T18:02:25Z

You mean the new (since Launcher 1.5) default args -Xmx1G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M ?

Someone 3x7 2014-07-29T18:45:48Z

I wasn't getting the default args and didn't notice they changed. I'll try those. Although, may be tomorrow. Getting sick again, which is unfortunately all too common these days.

One last note with just the args -Xms2G -Xmx4G: it seems to be a cycle its going through. Where occasionally the memory maxes out and it gets laggy. Plus changes in weather seem to reset this cycle(if it is one). When I was using -XX:ParallelGCThreads=4 -XX:+UseG1GC -XX:MaxGCPauseMillis=500 the seeming cycle was likely just slowed down, to where it took longer to reach the high point and stayed there longer.

Someone 3x7 2014-07-29T18:50:41Z

Ok, so I went ahead and tried those arguments right now and OMG the immediate difference is astounding. I know this isn't a place for feature suggestions but might I recommend a pop-up notification informing people of this change with the option to replace any current arguments?

I'll have to let it run for a day or two to see if this really fixes the issue, but, it looks promising.

kumasasa 2014-07-29T19:09:17Z

Are you talking of the new default args of Launcher 1.5 ?
As long as there are no custom arguments, the launcher replaces the old one with the new ones automatically.

Someone 3x7 2014-07-30T05:13:13Z

Yes, I am speaking of the new default arguments of launcher 1.5. Since I had custom arguments in all my profiles I was unaware of the change until you mentioned it. These arguments do run much better than what I had come up with on my own ages ago. After letting the game run all day afk in a skyblock style world where nothing was occurring(no redstone, no plants growing, no eligible place for mobs to successfully spawn) I can still see that the average memory usage climbs slowly, taking a slight dip when the weather changes. However, at this rate we would likely have to run the game a month straight before it causes any issues. Some day I might get that crazy...

kumasasa 2014-07-30T06:04:43Z

Someone 3x7 2014-07-30T19:30:34Z

A month might of been an overstatement. Full 24 hours later with nothing happening and its pinging 1gb, This could easily be an issue for servers if it affects them(I've just been doing single player). I'm going to shut it down to try the new snapshot though.

Someone 3x7 2014-08-03T19:30:51Z

So I think I finally narrowed it down. While the new default garbage collection settings sweep it under the rug a bit they don't make it disappear completely. It appears to be related to light sources(torches, glowstone, lava) in the render-able area. If I change the perspective to an area where there are no light sources in the render-able area whatever is causing the issue gets garbage collected. Also, changes in weather similarly cause it to be collected. Which would explain why 14w30b appeared to fix it at first since the render-able area correctly became much smaller. Also, whatever it is starts to build-up much faster when the game is minimized for a few hours. While I haven't been able to get it to break the game like it used to, I suspect it should be looked into as these kind of bugs have a tendency to fester over time. At this point though I've come to realize I am not being paid enough to put this much work into it 😛

kumasasa 2014-08-03T20:40:02Z

Ok, reopened that ticket.
If you pinpointed that definitely, please update the summary and description.

Someone 3x7 2015-02-18T23:23:53Z

This one takes some long testing that I just haven't felt up to for awhile. With the currently recommended and soon to be depreciated jvm gc settings each step takes at least a day. I will check it out again at some point. I've just had other more appealing interests as of late.

Someone 3x7 2015-02-22T02:54:40Z

Long story short, yes its still an issue. Sorta. I didn't let it run long enough at either 1gb or 4gb to get you a useful crash report, but, I could see the same trend after 4 hours in each. Then I fixed it. I was so incredibly bored at one point that I started writing books for a map where I could fit everything in it in one screenshot. Then I started thinking about how changing the JVM Arguments to the ones recommended in this thread significantly improved the situation. So I went out and dug into all the latest options for Java 8 and came up with this simple set of arguments:

-Xmx1G -Xms128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

With these arguments my memory usage never rises above 350mb even after hours on a map that used to launch at 650mb with the default arguments. Its either fixed or swept so far under the rug I'll never see it again. After stitching together the various notes at Oracle that ParNewGC appears in, its apparently a slightly-tweaked multi-threaded drop-in-replacement for CMSIncremental. I tried tinkering with the various settings relevant to ParNewGC, yet, it seems to work best when left to its own devices.

Edit: I've found that with double the memory ParNewGC runs a tad faster and uses less memory. Likely due to an internal survivor optimization that I couldn't force otherwise. -Xmx2G -Xms256m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

Someone 3x7 2015-02-23T13:04:07Z

While the settings I listed previously worked fine playing normally, I have an automation script that pushes minecraft to its limits in the course of preparing a large section of the nether for a map idea I've been tinkering with. Them settings buckled when running it. So I tinkered with the jvm arguments awhile and remembered the one note from oracle that stated UseParNewGC as a "drop in replacement" for CMSIncrementalMode. So I tried dropping it into the default settings (-Xmx1G -Xmn128M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-UseAdaptiveSizePolicy) and its working pretty good even when I'm playing abnormally.

kumasasa 2015-11-21T11:06:46Z

Is this still an issue in the current Minecraft Snapshot 15w47c or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Someone 3x7 2015-12-09T15:56:11Z

I cannot reliably test this or any other issue until MC-38134 is resolved. That said switching to UseParNewGC was a valid workaround/fix that I remember testing extensively. Thus, I doubt further testing is needed on this issue.