kiddailey

Agreed.  On Realms, this makes it impossible to enjoy the views at all or get much of a sense of direction, especially when you travel vertically.  From the top of the any significant mountain, all you can see is fog unless you look down.

I too concur with this being a showstopper bug. I have not logged into my own Realms server (which was left at 1.13) for fear of this issue causing major issues and have been contemplating cancelling paying for it until it's resolved 😞

In reply to the questions posted earlier:

• Did the light disappear also in the chunks you were standing in or only in distant chunks?
  Chunks I was in and nearby chunks

• Did the light disappear server-side and client-side (check with f3) WHILE standing afk?

• Or did it only disappear client-side after moving around or reloading the world?
  I'm unsure, but I seem to recall it being both and it has happened while AFKing. In every case, I did not see it disappear. Each time, everything was seemingly fine when I disconnected and then discovered to be broken after logging back into the server. And in every case, I was the only person near where I was. Others were on other parts of the server though (> 6000 blocks away) and sometimes travelling back-and-forth to the nether.

• Can you tell if the issue happened roughly at the same time for server and client (check with f3)?
  Unsure, but my assumption is yes based on the fact that I was the only one near the chunks, and the issue was present when I logged back in.

• Were there any nearby (redstone-)contraptions (at any point in time since server restart) that could cause a large number of block updates in a single tick?
  No.  On a small island in the middle of a deep ocean biome with not much of anything yet.

• Could you also experience the bug in singleplayer or only on dedicated servers?
  Only on servers so far, specifically Realms servers.

• For completeness: Are you close to/in the spawn chunks or far away from those?
  Far away. Over 6000 blocks away from spawn and other players.

A few observations from 1.14 while working with a very few number of trees on a small island in a deep ocean biome that originally generated without any trees:

• The issue occurs also when chopping OR growing trees, particularly noticeable when using bone meal.

• I am able to induce huge lag spikes (~9fps) in 1.14 by planting a bunch of saplings in a line and chopping them down once they've all grown.

• Biome blending has a definite impact, but turning it off does not completely remove issue. Lag is significantly worse with 15x15 blending though.

• Render distance doesn't appear to have any impact

• This happens even with single trees.

• Looking up while chopping the wood seems to make it slightly worse, but I'm not sure.

• Turning off smooth lighting dramatically reduces lag spikes.

Just wanted to mention that I've just experienced this on a brand-new 1.14 world on a Realms server, so it doesn't require you to upgrade a world created in a previous version. I don't know how or why it happened - I logged into the server into a torch-filled area with light-level 0 and a bunch of mobs.

The other day I was helping a friend troubleshoot the game after he just upgraded to 1.13.  It would launch, start and immediately freeze on him when he tried to load a world.  My hunch that the culprit was this bug was correct – the game was immediately using up all allocated RAM and freezing enough that he couldn't play the game.

His install was using the default settings (and a medium render distance), so the game was only being allocated 1GB.  Setting a custom JVM lanch string to allocate 4GB resolved the issue.

As I've mentioned above, I can concur with my own testing that it still is an issue with many (if not most) worlds I've tested in 1.13 with only 1GB allocated and a medium-high render distance and don't think it has been resolved completely.   In any case, it may be that the only remaining fix is to make the launcher allocated 4GB by default instead of 1GB.

I'm always generating a fresh, default creative world in the 1.13 versions with seed -9218963885634162416 (same seed as in the original report) for every test, and quitting the game completely between each test. 

Edit: Forgot to mention that I'm using bdm8's "g13" chunk loader (attached to bug report) for the tests.

I've only had time to do some quick tests with 1.13-pre10 and a 32chunk render distance and I've definitely seen improvement with allocations of 4GB or more.   Over an hour into testing 4GB/32chunks and RAM allocation sat completely steady at 71%, which is awesome!!

Any allocation less than that still seems about the same though.  Allocations of 2GB start having issues around 45min and with less RAM, sooner.  I realize that 32 chunks is a bit much for only 1-2GB of RAM, but I keep including these in my tests since it's around the default allocation in the launcher and 1.12 seemed to handle it acceptably.

Good luck to you all with the launch and thanks for all the hard work on this amazing release!

I've been doing some testing with bdm8's "g13" chunk loader structure block (thanks so much for putting that together, bdm8!) in pre-release7/launcher 2.1.1216 with a default, creative mode, same seed as original in report (-9218963885634162416) world and a 32 chunk render distance. The chunk loader simply teleports the user around at a high Y value every few seconds, allowing chunks to load between each teleport.

Nothing too surprising was revealed but thanks to the automation, it allowed me to easily test larger RAM allocations. The TLDR summary is that the issue exists regardless of how much RAM you allocate to the game.

Observations of note:

• It does not appear to matter how much memory you have allocated to the game. It may take longer the more you provide, but eventually the game will allocate and use all RAM and render the game unplayable.

• With less RAM allocation (1-2GB), the game appears to become unstable (frame rate drops) and unplayable (complete stalls/lag) at nearly the same time

• With more RAM allocation (8GB+), the game appears to become unstable before it reaches 100% allocated/used, with occasional drops in frame rates while chunks are loading/unloading and negatively impacting the system overall. For example, in my 8GB allocation tests, the game begins to have regular frame rate drops to 2-5fps at around 80 - 85% RAM allocation, eventually becoming completely unplayable at 100% allocation/usage.

• With 8GB allocated to the game (32chunk render), the game used up all allocated RAM after about 5-6 hours

• With 4GB allocated to the game (32chunk render), the game used up all allocated RAM after about 3-4 hours

• With 4GB allocated in a dark forest buffet world, the game used up all allocated RAM after about 1-2 hours

• Attempting to "Save and Quit" an 8GB allocated instance of the game that has used all 8GB causes the game to become completely unresponsive for 2-5 minutes while it tries to save and return to the main menu.

• To adjust the RAM in my tests, I used the default JVM arguments and only adjusted the -Xmx value, eg. "-Xmx8G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M"

Environments:

Windows 8.1 Pro 64bit, Intel Core i7 16GB RAM, JAVA 1.8.0_25 64bit, NVidia GeForce GTX 770/PIC/SSE2 4.6.0 NVIDIA 391.35
Windows 10, Intel Core i7, 16GB RAM, JAVA 1.8.0_25 64bit, Intel HD Graphics 620, 4.4.0 - Build 21.20.16.4550

Minecraft Launcher:

2.1.1216

JVM Arguments:

Default/none

Wow. That's an interesting find, and I can confirm I have the same experience. Just did a test in a Dark Forest Buffet world (seed: 1844439826410695340), creative mode, 1GB, 32 chunks and did not move at all after joining the world.

1 minute and 52 seconds in, the game had allocated 100% of the RAM. I saw my first (of many) lag spike 51 seconds later. I let it sit for a while longer and the game became completely unresponsive. Again, as Tedstar mentioned – without moving around at all.

Edit: It's not as severe, but this happens even in superflat worlds with nothing but the basic ground layers and very little (if any) transparency and decorations.

Some tests with 1.13-pre5. Could be more thorough, but I've got limited time at the moment. Hopefully it's useful.

The TLDR is – It definitely is better than it was in my original report/tests and mostly fine if players set their render distance more conservatively than they have in the past. But 1.12.2 sets the bar pretty high – I can't recall ever seeing a GC lag spike regardless of my render distance. The data below also seems to hint that there may be patterns or commonality between when the spikes happen.

Edit: Threw in a super-flat world with surprising results. Really feels like a chunk load/unload issue and that it may have been mitigated partially somehow but not really fixed 😞

—

Global Testing Parameters

• Same environment as original bug report

• 1GB allocated (default, not set with params)

• Exit game completely between each test

• Newly generated, default, creative world

• Using seed from original bug report (-9218963885634162416)

• After spawn, fly up to Y 125 and fly due-south (going up/down as needed)

• Go through at least three Garbage Collection lag spikes

• Note spikes as "Blocks traveled before spike (RAM usage% after GC)", secondary spikes are cumulative

Group 1 - Test Specific Parameters

• 32 chunk render distance (pushing the envelope of 1GB 🙂

• Sprint flying

Note that on test #5, my keyboard batteries died before the first spike and while I swapped them I could see the chunk rendering catching up to me and loading the full 32 chunks. The game was unplayable when I went to resume testing. In all my comments/test before, I've been sprint flying (as I did in the sample video posted with the report), but based on my experience with that test I thought I'd also perform a walk-flying test instead (where more chunks would be loading/unloading as I was moving). The results with walk flying were unsurprising:

Group 2 - Test Specific Parameters

• 32 Chunk render distance

• Walk flying

And lastly, I performed a test with rendering distance set to 16 chunks for comparison:

Group 3 - Test Specific Parameters

• 16 Chunk render distance

• Walk flying

Edit:

I wanted to do a quick test with a superflat world and was surprised:

Group 4 - Test Specific Paramaters

• 32 Chunk rendering distance

• Superflat (default)

• Sprint flying

• Seed: -3561884775657408351

I spent some time with 1.13pre-3 (1GB alloc) today with a few different seeds and it seems to have degraded a little. As I mentioned above with pre-2, I was getting 50% back after GC and it would take some time to reach 100% used again.

WIth pre-3, I'm only getting 35-40% back and usage climbs back up to 100% much more rapidly than with pre-2. Can anyone else confirm?

@Rikard: I've performed a few tests with 1.13pre-2 1GB and can concur that I'm also seeing garbage collection dropping usage down to around 50%. Allocation still remains at 100%, which is expected. I am seeing a significant "freeze" when the GC happens, but that is not surprising and the game does recover and remains playable.

I tested with a few different worlds, including a buffet warm ocean world with max render distance (the most problematic for me in the past) and see the same results.

The original bug as I reported was that the GC never cleared enough RAM causing the game to become unplayable and sometimes crashing, so it may be that this issue has been resolved.

Updating to confirm this issue persists in 18w22b and 18w22c

As a general observation, I would agree with Jen - this latest snapshot seems to suffer from this issue moreso than the previous. Additionally, the requirement of moving through the world appears less important.

I started a new world in 18w21a, spent an hour or so fiddling around with basic game start actions in the same general area (less than 1 region/32 chunks) and had to shut down and restart the game a couple of times to resolve the memory issue/sever frame drops.

I did perform some quick branch mining which may have generated a few chunks, but nothing as significant as my original tests posted above.

k, updated description to be more specific. Appreciate the help!

Ah! I see you're point - the height of the world is changing with structures. Makes sense to keep this as a dupe and just add a comment about structures on the other issue (or reopen🙂. Thanks!

Thanks for keeping me in check 😃 I need to get better searching apparently.

Thanks Kumasasa - I did search, but that bug doesn't exactly describe the issue. The player does spawn at the highest level in the seed I posted. The problem is that a shipwreck gets dumped on their head as I hinted at in my notes above 🙂

I've since learned that if you turn structures off, there is no issue. I've searched for another bug related to shipwrecks being placed on the spawnpoint and haven't found one. Should I adjust this bug and have it reopened, or create a new one?

Also, for some reason, an extra "2" got added to the end of that seed. Can you please remove it from the copy/paste on the other ticket? Thanks.

Updated to include that this impacts the latest snapshot - 18w21a