Timothy Miller

There needs to be SOME synchronous chunk loading. There's still a major bug where redstone doesn't load chunks properly. For that to happen, it's necessary for the main thread to demand chunk loading and wait on it.

My redstone accelerator is now integrated into the core of the Paper server modding framework. You can turn it on using a config file entry. Thank egg82 for doing the integration work.

The built-in profiler matches what I'm getting from async-profiler:

[00] tick - 99.95%/99.95%
[01] |   levels - 99.67%/99.67%
[02] |   |   world minecraft:overworld - 99.77%/99.45%
[03] |   |   |   tick - 100.00%/99.45%
[04] |   |   |   |   entities - 90.41%/89.92%
[05] |   |   |   |   |   regular - 95.87%/86.20%
[06] |   |   |   |   |   |   tick - 99.11%/85.44%
[07] |   |   |   |   |   |   |   minecraft:villager - 35.10%/29.99%
[08] |   |   |   |   |   |   |   |   ai - 66.84%/20.05%
[09] |   |   |   |   |   |   |   |   |   newAi - 99.41%/19.93%
[10] |   |   |   |   |   |   |   |   |   |   mob tick - 85.03%/16.95%
[11] |   |   |   |   |   |   |   |   |   |   |   brain - 99.03%/16.78%
[12] |   |   |   |   |   |   |   |   |   |   |   |   unspecified - 97.96%/16.44%

I just profiled the 1.14.1 release, and CPU load and the profile don't seem any different from what I was seeing in the snapshots. I think this bug should be reopened. Or if we're mistaken about it being POI, we can retitle the bug report or something.

Have a look here: https://www.dropbox.com/s/0v9ieuvabe5rt28/tree-1141.html?dl=0

I tried profiling in 1.14.1-pre2, and the performance is still bad there too. Here's another profile: https://www.dropbox.com/s/eg0h93swug3yi7o/tree-1141pre2.html?dl=0

KaptainWutax has investigated this a bunch, and he believes he understands the cause. Quoting him:

Tons of people are reporting to me that their villagers are disappearing in their iron farms. The error is ALWAYS a position desync, of this format : Wrong location! (-65, 4) should be (-54, 13), avk['Villager'/172716, l='world', x=-1037.30, y=89.00, z=70.30]. Some are related to sleeping on chunk borders(reproduceable consistently), and some seem completely random, in the center of chunks.

Here's a link to a video of the reproducible occurrence: https://streamable.com/0ivkh

async-profiler profile: https://www.dropbox.com/s/x242e4fjxc96l2a/tree-pre1-breeder.html?dl=0

FYI, this is not at all improved in 1.14.1-pre1. Here's a profile: https://www.dropbox.com/s/z036lp4eq7tzfse/tree-pre1-fs2.html?dl=0

KaptainWutax was kind enough to share his iron farm, and I profiled that too. The hot spot appears to also be in "villager brain" code, net/minecraft/entity/ai/brain/Brain, and deeper down, net/minecraft/entity/ai/brain/task/WanderAroundTask.

This uses excessive CPU for only 156 villagers. To observe this, you need to /tp to 200, 125, -200.

The profile is here: https://www.dropbox.com/s/5b953oe5qe4i3j8/tree-pre2-iron.html?dl=0
I will include the world download as an attachment, if it fits.

Profile from pre-release 2: https://www.dropbox.com/s/vgyi9g5631xxoe8/tree-pre2.html?dl=0

This kind of thing pops up a lot:
[19:52:44] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2240ms or 44 ticks behind

The CPU's pegged at 100% on my 4-core server, although it's better than previous versions, where the total CPU load was more than 150% in the best of cases. One thread uses around 85%, while there are lots of other threads using a few percent each.

Oh, and Adrian has my email address, if you want to contact me that way. Thanks again!

Hi, Prof,

We do have a test world. I don't want to post a link here due to privacy reasons, but I sent a download link to Boq. Also, feel free to contact me on Discord via EigenCraft (https://discord.gg/AbYpWWJ), and I can send you a link too.

Thanks.

In support of violine's statement, please be aware that PhiPro has made a full analysis of this bug (explained it in detail in a comment on this bug report), and this analysis was passed on directly to developers. Fixing it is not a simple one-liner, so they have bandaided over it for now, with full knowledge that this bandaid doesn't really fix the problem.

This is still a problem in 19w13a. According to boq, this relates to villager POI detection. I also uploaded a profile (from async-profiler) for 19w13a.

If I'm reading this right, then the fix for this looks pretty simple.

First check out line 37 of this patch: https://github.com/gnembon/carpetmod112/blob/staging/patches/net/minecraft/world/chunk/Chunk.java.patch

In net/minecraft/world/chunk/Chunk.java, there's a HashSet that needs to be replaced by a LinkedHashSet.

Secondly, search for "pistonSerializationFix" in https://github.com/gnembon/carpetmod112/blob/staging/patches/net/minecraft/tileentity/TileEntityPiston.java.patch

Earthcomputer is the one who fixed it, so maybe if I did an inadequate job here, that will encourage him to add a deeper explanation. 🙂

My two cents are that this is an unnecessary behavioral regression. If we see Minecraft as an application platform (which it most certainly is), and we see blast chambers as an application, then this change is an undesirable break in backward compatibility for a pre-existing application. This is something that the Windows development team takes VERY seriously. If you consider this to be a maintenance issue for Mojang developers, what about the maintenance impact for all the players who use this mechanic?

That's all I have to say. If anyone wants to debate the self-evident fact that Minecraft is an application platform, we can take this to /r/mojira.

This bug report should be marked WAI.

I have been unable to reproduce this bug in 1.13.2. Looking at a decompile, it appears that the developers fixed this by applying a 0.001 block margin around the Entity when computing collisions with blocks. I hesitate to formally declare the bug fixed without developer comment. However, my test setup was able to reliably reproduce this bug over and over again in 1.13.2, but no deaths occur in 1.13.2, and I found the code that applies the margin, and some debug trace code clearly associates the function applying the margin with block collisions.

I'm not sure if this is exactly Xcom's fix, but since he was the one that suggested applying a margin, we should at least partially credit the fix to him. Many thanks to Xcom and to the developer(s) that decided to adopt his solution.

Now that I think about it, if azt.a is related to mob counting, why is the server trying to count mobs in the first place? Shouldn't it be keeping a running total (or set thereof) that is incremented when one spawns, decremented when one despawns, and modified when chunks are loaded and unloaded? If it's counting every tick for fear of the running total getting out of sync with the real total, then there are some much more serious problems.

18w44a hasn't done anything to help with this. Here's the top of the profile tree now:

(t 100.0,s 13.1) java.lang.Thread::run
  (t 86.9,s  1.7) net.minecraft.server.MinecraftServer::run
   (t 52.9,s 52.9) java.lang.Thread::yield
   (t 14.0,s  0.0) net.minecraft.server.MinecraftServer::a
    (t 14.0,s  0.0) ti::b
     (t 14.0,s  0.0) net.minecraft.server.MinecraftServer::b
      (t 13.8,s  0.0) ua::a
       (t 13.7,s  0.0) tz::a
        (t 13.5,s  2.1) tz::n
         (t  3.4,s  2.9) azp::c
          (t  0.5,s  0.0) java.util.TreeMap::get
           (t  0.5,s  0.4) java.util.TreeMap::getEntry
            (t  0.1,s  0.1) java.lang.String::compareTo
         (t  2.2,s  0.0) tq::c
          (t  1.2,s  0.0) java.util.concurrent.CompletableFuture::getNow
           (t  1.2,s  1.2) java.util.concurrent.CompletableFuture::reportJoin
          (t  0.6,s  0.0) com.mojang.datafixers.util.Either$Left::left
           (t  0.6,s  0.5) java.util.Optional::of
            (t  0.1,s  0.1) java.util.Optional::<init>
          (t  0.4,s  0.4) com.mojang.datafixers.util.Either$Right::left
         (t  2.2,s  0.2) azt::a
          (t  0.8,s  0.6) java.util.Random::nextInt
           (t  0.2,s  0.1) java.util.Random::next
            (t  0.1,s  0.1) java.util.concurrent.atomic.AtomicLong::compareAndSet