mirrors/papermc
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
papermc/Spigot-Server-Patches/0460-Speed-up-processing-of-chunk-loads-and-generation.patch

219 lines
11 KiB
Diff
Raw Normal View History

Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
From df60dff93009e0cf28dc3e5b984d1a5afbf93bd2 Mon Sep 17 00:00:00 2001
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
From: Aikar <aikar@aikar.co>
Date: Thu, 9 Apr 2020 00:09:26 -0400
Subject: [PATCH] Speed up processing of chunk loads and generation
Credit to Spotted for the idea
A lot of the new chunk system requires constant back and forth the main thread
to handle priority scheduling and ensuring conflicting tasks do not run at the
same time.
The issue is, these queues are only checked at either:
A) Sync Chunk Loads
B) End of Tick while sleeping
This results in generating chunks sitting waiting for a full tick to
complete before it will even start the next unit of work to do.
Additionally, this also delays loading of chunks until this same timing.
We will now periodically poll the chunk task queues throughout the tick,
looking for work to do.
We do this in a fair method that considers all worlds, not just the one being
ticked, so that each world can get 1 task procesed each before the next pass.
We also cap the throughput of these task processes to 1 per world per 0.1ms or
200 max per tick, to ensure that high volume of tasks do not overload the current
tick time.
In a view distance of 15, chunk loading performance was visually faster on the client.
Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
diff --git a/src/main/java/co/aikar/timings/MinecraftTimings.java b/src/main/java/co/aikar/timings/MinecraftTimings.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
index 69e26a8267..434833d50e 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
--- a/src/main/java/co/aikar/timings/MinecraftTimings.java
+++ b/src/main/java/co/aikar/timings/MinecraftTimings.java
@@ -13,6 +13,7 @@ import java.util.Map;
public final class MinecraftTimings {
public static final Timing serverOversleep = Timings.ofSafe("Server Oversleep");
+ public static final Timing midTickChunkTasks = Timings.ofSafe("Mid Tick Chunk Tasks");
public static final Timing playerListTimer = Timings.ofSafe("Player List");
public static final Timing commandFunctionsTimer = Timings.ofSafe("Command Functions");
public static final Timing connectionTimer = Timings.ofSafe("Connection Handler");
diff --git a/src/main/java/net/minecraft/server/ChunkProviderServer.java b/src/main/java/net/minecraft/server/ChunkProviderServer.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
index 3d79e756d9..5fea6e56d5 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
--- a/src/main/java/net/minecraft/server/ChunkProviderServer.java
+++ b/src/main/java/net/minecraft/server/ChunkProviderServer.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -683,6 +683,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
this.world.getMethodProfiler().enter("purge");
this.world.timings.doChunkMap.startTiming(); // Spigot
this.chunkMapDistance.purgeTickets();
+ this.world.getMinecraftServer().midTickLoadChunks(); // Paper
this.tickDistanceManager();
this.world.timings.doChunkMap.stopTiming(); // Spigot
this.world.getMethodProfiler().exitEnter("chunks");
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -692,6 +693,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
this.world.timings.doChunkUnload.startTiming(); // Spigot
this.world.getMethodProfiler().exitEnter("unload");
this.playerChunkMap.unloadChunks(booleansupplier);
+ this.world.getMinecraftServer().midTickLoadChunks(); // Paper
this.world.timings.doChunkUnload.stopTiming(); // Spigot
this.world.getMethodProfiler().exit();
this.clearCache();
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -750,7 +752,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
entityPlayer.playerNaturallySpawnedEvent.callEvent();
};
// Paper end
- this.playerChunkMap.forEachVisibleChunk((playerchunk) -> { // Paper - safe iterator incase chunk loads, also no wrapping
+ final int[] chunksTicked = {0}; this.playerChunkMap.forEachVisibleChunk((playerchunk) -> { // Paper - safe iterator incase chunk loads, also no wrapping
Optional<Chunk> optional = ((Either) playerchunk.b().getNow(PlayerChunk.UNLOADED_CHUNK)).left();
if (optional.isPresent()) {
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -833,6 +835,7 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
this.world.timings.chunkTicks.startTiming(); // Spigot // Paper
this.world.a(chunk, k);
this.world.timings.chunkTicks.stopTiming(); // Spigot // Paper
+ if (chunksTicked[0]++ % 10 == 0) this.world.getMinecraftServer().midTickLoadChunks(); // Paper
}
}
});
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
@@ -974,6 +977,38 @@ public class ChunkProviderServer extends IChunkProvider {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
super.executeTask(runnable);
}
+ // Paper start
+ private long lastChunkTask = 0;
+ public void midTickLoadChunks() {
+ MinecraftServer server = ChunkProviderServer.this.world.getMinecraftServer();
+ try (co.aikar.timings.Timing ignored = co.aikar.timings.MinecraftTimings.midTickChunkTasks.startTiming()) {
+ while (server.canSleepForTick()) {
+ try {
+ // always try to load chunks as long as we aren't falling behind, restrain generation/other updates only.
+ boolean execChunkTask = com.destroystokyo.paper.io.chunk.ChunkTaskManager.pollChunkWaitQueue() || ChunkProviderServer.this.world.asyncChunkTaskManager.pollNextChunkTask(); // Paper
Fix issues with 167 causing crashes due to missing chunks - Fixes #3122 Forgot to flip the pending boolean back to false, causing it to copy empty data on the next tick if nothing else triggered a load. haven't managed to actually reproduce the crash others got, but did verify that the bad copy was occurring erasing the data. also fixed a bug with chunk load callback not executing before another one was scheduled.
2020-04-10 18:11:46 +00:00
+ if (ChunkProviderServer.this.tickDistanceManager() || execChunkTask) {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
+ continue;
+ }
+ long now = System.nanoTime();
+ // cap to 1 task every 0.1ms per world and max 200 tasks per tick.
+ // Anything that doesn't make it past this can load during sleep
+ // we do not want to use this.executeNext as that also processes chunk loads and might count against task counter.
+ // We also have already ticked the distance manager above too.
+ if (server.chunksTasksRan < 200 && now - lastChunkTask > 100000 && super.executeNext()) {
+ ChunkProviderServer.this.lightEngine.queueUpdate();
+ server.chunksTasksRan++;
+ lastChunkTask = now;
+ }
+ break;
+ } finally {
+ // from below: process pending Chunk loadCallback() and unloadCallback() after each run task
+ playerChunkMap.callbackExecutor.run();
+ }
+ }
+ }
+ }
+ // Paper end
+
@Override
protected boolean executeNext() {
// CraftBukkit start - process pending Chunk loadCallback() and unloadCallback() after each run task
diff --git a/src/main/java/net/minecraft/server/MinecraftServer.java b/src/main/java/net/minecraft/server/MinecraftServer.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
index e35bacac71..2f424e6e8b 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
--- a/src/main/java/net/minecraft/server/MinecraftServer.java
+++ b/src/main/java/net/minecraft/server/MinecraftServer.java
Load Spawn Chunks Asynchronously and Spiral Out Ensures absolute center is first in priority Speeds up server startup
2020-04-19 10:01:07 +00:00
@@ -907,6 +907,7 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
// Paper end
tickSection = curTime;
}
+ chunksTasksRan = 0; // Paper
// Spigot end
//MinecraftServer.currentTick = (int) (System.currentTimeMillis() / 50); // CraftBukkit // Paper - don't overwrite current tick time
Load Spawn Chunks Asynchronously and Spiral Out Ensures absolute center is first in priority Speeds up server startup
2020-04-19 10:01:07 +00:00
@@ -977,7 +978,7 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
}
- private boolean canSleepForTick() {
+ public boolean canSleepForTick() { // Paper
// CraftBukkit start
return this.forceTicks || this.isEntered() || SystemUtils.getMonotonicMillis() < (this.ac ? this.ab : this.nextTick);
}
Load Spawn Chunks Asynchronously and Spiral Out Ensures absolute center is first in priority Speeds up server startup
2020-04-19 10:01:07 +00:00
@@ -1005,6 +1006,20 @@ public abstract class MinecraftServer extends IAsyncTaskHandlerReentrant<TickTas
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
});
}
+ // Paper start
+ public int chunksTasksRan = 0;
+ public void midTickLoadChunks() {
+ if (!this.canSleepForTick()) {
+ return;
+ }
+
+ Iterator<WorldServer> iterator = this.getWorlds().iterator();
+ while (this.canSleepForTick() && iterator.hasNext()) {
+ iterator.next().getChunkProvider().serverThreadQueue.midTickLoadChunks();
+ }
+ }
+ // Paper end
+
@Override
protected TickTask postToMainThread(Runnable runnable) {
return new TickTask(this.ticks, runnable);
diff --git a/src/main/java/net/minecraft/server/PlayerChunkMap.java b/src/main/java/net/minecraft/server/PlayerChunkMap.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
index e61ddeb1ff..92c9ab43d7 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
--- a/src/main/java/net/minecraft/server/PlayerChunkMap.java
+++ b/src/main/java/net/minecraft/server/PlayerChunkMap.java
Fix issues with 167 causing crashes due to missing chunks - Fixes #3122 Forgot to flip the pending boolean back to false, causing it to copy empty data on the next tick if nothing else triggered a load. haven't managed to actually reproduce the crash others got, but did verify that the bad copy was occurring erasing the data. also fixed a bug with chunk load callback not executing before another one was scheduled.
2020-04-10 18:11:46 +00:00
@@ -793,7 +793,7 @@ public class PlayerChunkMap extends IChunkLoader implements PlayerChunk.d {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
CompletableFuture<Either<IChunkAccess, PlayerChunk.Failure>> ret = new CompletableFuture<>();
Consumer<ChunkRegionLoader.InProgressChunkHolder> chunkHolderConsumer = (ChunkRegionLoader.InProgressChunkHolder holder) -> {
- PlayerChunkMap.this.executor.addTask(() -> {
+ com.destroystokyo.paper.io.chunk.ChunkTaskManager.queueChunkWaitTask(() -> {
ret.complete(syncLoadComplete.apply(holder, null));
});
};
diff --git a/src/main/java/net/minecraft/server/WorldServer.java b/src/main/java/net/minecraft/server/WorldServer.java
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
index 33de08a8ac..4a63536dee 100644
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
--- a/src/main/java/net/minecraft/server/WorldServer.java
+++ b/src/main/java/net/minecraft/server/WorldServer.java
@@ -420,6 +420,7 @@ public class WorldServer extends World {
}
timings.scheduledBlocks.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
gameprofilerfiller.exitEnter("raid");
this.timings.raids.startTiming(); // Paper - timings
this.persistentRaid.a();
@@ -432,6 +433,7 @@ public class WorldServer extends World {
timings.doSounds.startTiming(); // Spigot
this.ad();
timings.doSounds.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
this.ticking = false;
gameprofilerfiller.exitEnter("entities");
boolean flag3 = true || !this.players.isEmpty() || !this.getForceLoadedChunks().isEmpty(); // CraftBukkit - this prevents entity cleanup, other issues on servers with no players
Delay unsafe actions until after entity ticking is done - Fixes #3114 This will help prevent many cases of unregistering entities during entity ticking Currently delays Chunk Unloads and Async Chunk load callbacks Also dropped mid ticking chunk tasks during entity ticking to reduce this risk
2020-04-12 01:31:40 +00:00
@@ -517,6 +519,7 @@ public class WorldServer extends World {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
timings.entityTick.stopTiming(); // Spigot
this.tickingEntities = false;
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
try (co.aikar.timings.Timing ignored = this.timings.newEntities.startTiming()) { // Paper - timings
while ((entity = (Entity) this.entitiesToAdd.poll()) != null) {
Delay unsafe actions until after entity ticking is done - Fixes #3114 This will help prevent many cases of unregistering entities during entity ticking Currently delays Chunk Unloads and Async Chunk load callbacks Also dropped mid ticking chunk tasks during entity ticking to reduce this risk
2020-04-12 01:31:40 +00:00
@@ -527,7 +530,9 @@ public class WorldServer extends World {
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
gameprofilerfiller.exit();
timings.tickEntities.stopTiming(); // Spigot
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
this.tickBlockEntities();
+ this.getMinecraftServer().midTickLoadChunks(); // Paper
}
gameprofilerfiller.exit();
--
Improve Async Login so pending connections dont get exposed We still keep vanilla process of waiting for existing session to be removed before logging in by storing a separate map of pending. also fire the callback using executor incase further recursion causes any trouble
2020-04-24 09:33:33 +00:00
2.25.1
Speed up processing of chunk loads and generation Credit to Spotted for the idea A lot of the new chunk system requires constant back and forth the main thread to handle priority scheduling and ensuring conflicting tasks do not run at the same time. The issue is, these queues are only checked at either: A) Sync Chunk Loads B) End of Tick while sleeping This results in generating chunks sitting waiting for a full tick to complete before it will even start the next unit of work to do. Additionally, this also delays loading of chunks until this same timing. We will now periodically poll the chunk task queues throughout the tick, looking for work to do. We do this in a fair method that considers all worlds, not just the one being ticked, so that each world can get 1 task procesed each before the next pass. We also cap the throughput of these task processes to 1 per world per 0.1ms or 200 max per tick, to ensure that high volume of tasks do not overload the current tick time. In a view distance of 15, chunk loading performance was visually faster on the client. Flying at high speed in spectator mode was able to keep up with chunk loading (as long as they are already generated)
2020-04-09 06:25:18 +00:00
Reference in a new issue Copy permalink