YUNG's Better Caves (Forge)

YUNG's Better Caves (Forge)

41M Downloads

Slow chunkloading

Darkere opened this issue ยท 20 comments

commented

Hello we are experiencing an issue where chunks outside the overworld load in incredibly slowly.

I've done some profiling and found some references to Better Caves, hoping there might be an issue there.
image

https://spark.lucko.me/#wl2OebObuC

Profiled all threads here. Potential issue is under Worker Thread.

Pack is Enigmatica 6 v0.4.1
BetterCaves-Forge-1.16.4-1.1.1
Forge 36.0.40

commented

Something that may be causing this issue is that when falling back to default carvers, you don't seem to pop from the carving context stack:

https://github.com/yungnickyoung/YUNGs-Better-Caves/blob/3ce876dcd9cf488fa55a1e5ec4c32af591c49f7a/src/main/java/com/yungnickyoung/minecraft/bettercaves/world/carver/BetterCavesCarver.java#L65

I assumed earlier today in Discord that this would probably lead to an infinite loop outside of whitelisted dimensions as you're just constantly looking at the top of the stack without actually modifying it, which would in turn explain why the thread keeps stalling here.

commented

Hmm, I'm not sure that's the case. It seems to be waiting during the call to World#getChunk in IWorldReader#getNoiseBiome when trying to fetch the biome at the given position. This getChunk call should resolve properly, since its required status is ChunkStatus.BIOMES - a phase of chunk generation that is three phases before CARVERS. If I had to guess, perhaps you have a biome generation mod that is taking some time?

I don't see how not popping the context would result in any thread hanging. In fact, not popping the context is intentional - in vanilla generation, the carveRegion method will be called 289 times (17 x 17) per chunk. It is necessary that we don't pop the context when defaulting to vanilla gen, or else the chunk will only process 1 time instead of 289. Furthermore, if it's a case of the world simply loading slowly, then it can't be any sort of strange infinite loop, as that would cause worldgen to hang entirely.

Edit - Also, not popping the context at all should be totally fine, since each chunk independently has its own context in the form of a ThreadLocal.

commented

Ah that's fair, as I said forgot to say, I really only took a cursory glance so I kinda expected that not to be the case lol

commented

My experience was in both the nether and the end. As soon as I came out of the portal I could only load 1/2 chunks around myself, and a new one would load in like 5/10 minutes later.

commented

Were you guys able to figure out the cause?

commented

We ended up making a test server with 5 people and reproduced it there. We removed better caves afterwards and were no longer able to reproduce it.

With that we decided to temporarily remove the mod from the pack. Still no idea if its better caves or some bad interaction. But chunks loading in one by one every 10 seconds is not a state we could leave the pack in.

Tracking it down is rather difficult as it requires quite a few people online to even appear.

commented

Huh. Does the slow chunk loading happen instantly, or does it get worse over time? Also, what dimension(s) are you testing in?

commented

Yup, and you can get the chunks to load sometimes by having someone teleport to you. This is not just new chunk generation either, already generated chunks can have this same issue. One example was some (albeit insane) people on our server decided to bridge from the main end island to the outer islands... It took them multiple days with the slow chunk loading, but if you teleported to them in the middle of their bridge, you could not run back to the main end island without waiting on chunks to load for many minutes, these chunks are obviously generated as they bridged right through them.

commented

Yup, and you can get the chunks to load sometimes by having someone teleport to you. This is not just new chunk generation either, already generated chunks can have this same issue. One example was some (albeit insane) people on our server decided to bridge from the main end island to the outer islands... It took them multiple days with the slow chunk loading, but if you teleported to them in the middle of their bridge, you could not run back to the main end island without waiting on chunks to load for many minutes, these chunks are obviously generated as they bridged right through them.

This makes me think it's not Better Caves, as BC is only concerned with initial world generation.

Has anyone clearly pinpointed BC as the cause?

commented

Still not sure what could cause this, but since the thread locking occurs during the call to getNoiseBiome, I tried replacing that function call with a more proper method of biome fetching.

You can try the release here.

Let me know if it changes anything!

commented

Any update? I can't test this myself as I'm unable to reproduce the issue.

commented

The worldgen threadpool is limited in size. If it's currently saturated because chunks are generating then new tasks will be queued rather than executed immediately. This makes it unsafe to ask for more chunks to generate from within a currently generating chunk because you end up with active tasks waiting on queued tasks and the queued tasks are waiting on the active ones to complete before they get to execute. It'd be much more common on lower core count cpus since mojang scale the pool size based on available processors.

commented

I don't believe I ask for additional chunks, though. The logic used when defaulting to vanilla carvers is taken straight from vanilla.

commented

It did in the previous commit which I believe is what the report was made using.
https://github.com/yungnickyoung/YUNGs-Better-Caves/blob/5cc5f7623105f14a52051a46dbb1bcf581f3f9e9/src/main/java/com/yungnickyoung/minecraft/bettercaves/world/carver/BetterCavesCarver.java#L103

You can see in the profiling data screenshot above that the call to World#getNoiseBiome requests a chunk from the chunk provider which triggers a new gen task. Mojang take a bunch of weird steps to avoid exposing the ServerWorld to world-gen for this very reason. I'd imagine their source code is littered with comments and javadocs (that we unfortunately don't get to see) warning about it ๐Ÿ˜…

commented

Ah, okay. Well, I replaced that function call with the vanilla-provided biomePos function, which I thought might fix the issue since both vanilla and my own carvers already go nuts with that function without a problem. That fix is included in the JAR I posted above (reposting here for clarity), but no one has tested it yet ๐Ÿ˜ž

commented

@Lyx2k Is this only happening in the End? I don't see any references to Better Caves in that spark log, although I do see some mentions of Better End.

commented

@yungnickyoung

here is a log from the nether where it happens too https://spark.lucko.me/5tgARQAnsR

commented

Hey you.

I tested it with ur beta and it has still heavy loading or chunk creation. Here is the spark log: https://spark.lucko.me/jLUEuQsZUK

Enigmatica 6 - 0.4.3 Modpack with regular world type and not terraforged

Greetz

commented

I have no idea. I don't see anything in the spark log that points to something caused by Better Caves. And the only explicit reference to my code is the delegation to the default carver itself, which takes up a mere 0.44% of the load on Worker-Main.

commented

So it could be probably something else. I would say as long no one else comment something here the problem is solved or burried.