Mirrors/Paper
3
0
Fork 1
Mirror von https://github.com/PaperMC/Paper.git synchronisiert 2024-11-15 12:30:06 +01:00
Code Issues Projekte Releases Wiki Aktivität
a70618cd5c
Paper/Spigot-Server-Patches/0202-Improved-Async-Task-Scheduler.patch

371 Zeilen
15 KiB
Diff
Originalformat Normale Ansicht Verlauf

Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
From: Aikar <aikar@aikar.co>
Date: Fri, 16 Mar 2018 22:59:43 -0400
Subject: [PATCH] Improved Async Task Scheduler
The Craft Scheduler still uses the primary thread for task scheduling.
This results in the main thread still having to do work as part of the
dispatching of async tasks.
If plugins make use of lots of async tasks, such as particle emitters
that want to keep the logic off the main thread, the main thread still
receives quite a bit of load from processing all of these queued tasks.
Additionally, resizing and managing the pending entries for all of
these asynchronous tasks takes up time on the main thread too.
This commit replaces the implementation of the scheduler when working
with asynchronous tasks, by forwarding calls to the new scheduler.
The Async Scheduler uses a single thread executor for "management" tasks.
The Management Thread is responsible for all adding and dispatching of
scheduled tasks.
The mainThreadHeartbeat will send a heartbeat task to the management thread
with the currentTick value, so that it can find which tasks to execute.
Scheduling of an async tasks also dispatches a management task, ensuring
that any Queue resizing operation occurs off of the main thread.
The async queue uses a complete separate PriorityQueue, ensuring that resize
operations are decoupled from the sync tasks queue.
diff --git a/src/main/java/org/bukkit/craftbukkit/scheduler/CraftAsyncScheduler.java b/src/main/java/org/bukkit/craftbukkit/scheduler/CraftAsyncScheduler.java
new file mode 100644
Rebuild all patches using the new rebuild pattern
2020-05-06 11:48:49 +02:00
index 0000000000000000000000000000000000000000..3c1992e212a6d6f1db4d5b807b38d71913619fc0
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
--- /dev/null
+++ b/src/main/java/org/bukkit/craftbukkit/scheduler/CraftAsyncScheduler.java
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
@@ -0,0 +1,122 @@
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+/*
+ * Copyright (c) 2018 Daniel Ennis (Aikar) MIT License
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ * LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ * OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+package org.bukkit.craftbukkit.scheduler;
+
+import com.destroystokyo.paper.ServerSchedulerReportingWrapper;
+import com.google.common.util.concurrent.ThreadFactoryBuilder;
+import org.bukkit.plugin.Plugin;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.concurrent.Executor;
+import java.util.concurrent.Executors;
Remove the immediate dispatch optimization and adjust thread executors hopefully will resolve #1049
2018-03-19 01:09:12 +01:00
+import java.util.concurrent.SynchronousQueue;
+import java.util.concurrent.ThreadPoolExecutor;
+import java.util.concurrent.TimeUnit;
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+
+public class CraftAsyncScheduler extends CraftScheduler {
+
Remove the immediate dispatch optimization and adjust thread executors hopefully will resolve #1049
2018-03-19 01:09:12 +01:00
+ private final ThreadPoolExecutor executor = new ThreadPoolExecutor(
+ 4, Integer.MAX_VALUE,30L, TimeUnit.SECONDS, new SynchronousQueue<>(),
+ new ThreadFactoryBuilder().setNameFormat("Craft Scheduler Thread - %1$d").build());
+ private final Executor management = Executors.newSingleThreadExecutor(new ThreadFactoryBuilder()
+ .setNameFormat("Craft Async Scheduler Management Thread").build());
check that a task is valid before executing incase it was cancelled elsewhere also set runners in the short circuit path so we know of the pending task incase its long running
2018-03-17 17:58:27 +01:00
+ private final List<CraftTask> temp = new ArrayList<>();
Remove the immediate dispatch optimization and adjust thread executors hopefully will resolve #1049
2018-03-19 01:09:12 +01:00
+
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ CraftAsyncScheduler() {
+ super(true);
Remove the immediate dispatch optimization and adjust thread executors hopefully will resolve #1049
2018-03-19 01:09:12 +01:00
+ executor.allowCoreThreadTimeOut(true);
+ executor.prestartAllCoreThreads();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ }
+
+ @Override
+ public void cancelTask(int taskId) {
+ this.management.execute(() -> this.removeTask(taskId));
+ }
+
+ private synchronized void removeTask(int taskId) {
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
+ parsePending();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ this.pending.removeIf((task) -> {
+ if (task.getTaskId() == taskId) {
+ task.cancel0();
+ return true;
+ }
+ return false;
+ });
+ }
+
+ @Override
+ public void mainThreadHeartbeat(int currentTick) {
+ this.currentTick = currentTick;
+ this.management.execute(() -> this.runTasks(currentTick));
+ }
+
+ private synchronized void runTasks(int currentTick) {
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
+ parsePending();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ while (!this.pending.isEmpty() && this.pending.peek().getNextRun() <= currentTick) {
+ CraftTask task = this.pending.remove();
check that a task is valid before executing incase it was cancelled elsewhere also set runners in the short circuit path so we know of the pending task incase its long running
2018-03-17 17:58:27 +01:00
+ if (executeTask(task)) {
+ final long period = task.getPeriod();
+ if (period > 0) {
+ task.setNextRun(currentTick + period);
+ temp.add(task);
+ }
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ }
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
+ parsePending();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ }
+ this.pending.addAll(temp);
check that a task is valid before executing incase it was cancelled elsewhere also set runners in the short circuit path so we know of the pending task incase its long running
2018-03-17 17:58:27 +01:00
+ temp.clear();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ }
+
check that a task is valid before executing incase it was cancelled elsewhere also set runners in the short circuit path so we know of the pending task incase its long running
2018-03-17 17:58:27 +01:00
+ private boolean executeTask(CraftTask task) {
+ if (isValid(task)) {
+ this.runners.put(task.getTaskId(), task);
+ this.executor.execute(new ServerSchedulerReportingWrapper(task));
+ return true;
+ }
+ return false;
+ }
+
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ @Override
+ public synchronized void cancelTasks(Plugin plugin) {
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
+ parsePending();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ for (Iterator<CraftTask> iterator = this.pending.iterator(); iterator.hasNext(); ) {
check that a task is valid before executing incase it was cancelled elsewhere also set runners in the short circuit path so we know of the pending task incase its long running
2018-03-17 17:58:27 +01:00
+ CraftTask task = iterator.next();
+ if (task.getTaskId() != -1 && (plugin == null || task.getOwner().equals(plugin))) {
+ task.cancel0();
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ iterator.remove();
+ }
+ }
+ }
+
+ /**
+ * Task is not cancelled
+ * @param runningTask
+ * @return
+ */
+ static boolean isValid(CraftTask runningTask) {
Update CB/S
2018-03-31 11:34:25 +02:00
+ return runningTask.getPeriod() >= CraftTask.NO_REPEATING;
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ }
+}
diff --git a/src/main/java/org/bukkit/craftbukkit/scheduler/CraftScheduler.java b/src/main/java/org/bukkit/craftbukkit/scheduler/CraftScheduler.java
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
index ff855035ae55df37d68b284ac18976c46d388af2..99ea0aabadfac2a68ec67a7d49831025820de2c3 100644
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
--- a/src/main/java/org/bukkit/craftbukkit/scheduler/CraftScheduler.java
+++ b/src/main/java/org/bukkit/craftbukkit/scheduler/CraftScheduler.java
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -63,7 +63,7 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
/**
* Main thread logic only
*/
- private final PriorityQueue<CraftTask> pending = new PriorityQueue<CraftTask>(10,
+ final PriorityQueue<CraftTask> pending = new PriorityQueue<CraftTask>(10, // Paper
new Comparator<CraftTask>() {
Update Upstream
2019-05-06 04:58:04 +02:00
@Override
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
public int compare(final CraftTask o1, final CraftTask o2) {
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -80,12 +80,13 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
/**
* These are tasks that are currently active. It's provided for 'viewing' the current state.
*/
- private final ConcurrentHashMap<Integer, CraftTask> runners = new ConcurrentHashMap<Integer, CraftTask>();
Update Upstream
2018-06-21 05:29:33 +02:00
+ final ConcurrentHashMap<Integer, CraftTask> runners = new ConcurrentHashMap<Integer, CraftTask>(); // Paper
/**
* The sync task that is currently running on the main thread.
*/
private volatile CraftTask currentTask = null;
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
- private volatile int currentTick = -1;
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 220bc594 #486: Add method to get player's attack cooldown 21853d39 SPIGOT-5681: Increase max plugin channel size 5b972adc Improve build process b55e58d9 Note which custom generator is missing required method CraftBukkit Changes: 893ad93b #650: Add method to get player's attack cooldown ef706b06 #655: Added support for the VM tag jansi.passthrough when processing messages sent to a ColouredConsoleSender. e0cfb347 SPIGOT-5689: Fireball.setDirection increases velocity too much 94cb030f SPIGOT-5673: swingHand API does not show to self b331a055 SPIGOT-5680: isChunkGenerated creates empty region files e1335932 Improve build process a8ec1d60 Add a couple of method null checks to CraftWorld ce66f693 Misc checkstyle fixes 8bd0e9ab SPIGOT-5669: Fix Beehive.isSedated Spigot Changes: 2040c4c4 SPIGOT-5677, MC-114796: Fix portals generating outside world border ab8f6b5a Rebuild patches e7dc2f53 Rebuild patches
2020-04-27 09:34:45 +02:00
+ // Paper start - Improved Async Task Scheduler
+ volatile int currentTick = -1;/*
private final Executor executor = Executors.newCachedThreadPool(new ThreadFactoryBuilder().setNameFormat("Craft Scheduler Thread - %d").build());
private CraftAsyncDebugger debugHead = new CraftAsyncDebugger(-1, null, null) {
@Override
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -94,12 +95,31 @@ public class CraftScheduler implements BukkitScheduler {
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 220bc594 #486: Add method to get player's attack cooldown 21853d39 SPIGOT-5681: Increase max plugin channel size 5b972adc Improve build process b55e58d9 Note which custom generator is missing required method CraftBukkit Changes: 893ad93b #650: Add method to get player's attack cooldown ef706b06 #655: Added support for the VM tag jansi.passthrough when processing messages sent to a ColouredConsoleSender. e0cfb347 SPIGOT-5689: Fireball.setDirection increases velocity too much 94cb030f SPIGOT-5673: swingHand API does not show to self b331a055 SPIGOT-5680: isChunkGenerated creates empty region files e1335932 Improve build process a8ec1d60 Add a couple of method null checks to CraftWorld ce66f693 Misc checkstyle fixes 8bd0e9ab SPIGOT-5669: Fix Beehive.isSedated Spigot Changes: 2040c4c4 SPIGOT-5677, MC-114796: Fix portals generating outside world border ab8f6b5a Rebuild patches e7dc2f53 Rebuild patches
2020-04-27 09:34:45 +02:00
}
};
private CraftAsyncDebugger debugTail = debugHead;
+
+ */ // Paper end
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
private static final int RECENT_TICKS;
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 5b680f0b Note maximum objective score length in documentation CraftBukkit Changes: 5932f8a7 Load default world spawn areas in consistent order 3a5dc78f Fix confusing migration message appearing on fresh server 516a408f Remove redundant CraftBukkit change for secondary world data 73a2c749 Process conversation input on the main thread. 100c3f07 Cap Objective Score Length 6e842759 Cross World Entity Teleportation 7deba1c6 Check for blank OfflinePlayer Names f2746a5e Descriptive kick reasons instead of Nope! b0212308 Cap Channel Registrations a610dcd8 Identify CraftScheduler threads with useful names Spigot Changes: 19c3c5a5 Rebuild patches
2019-01-06 18:15:21 +01:00
static {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
RECENT_TICKS = 30;
}
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
+
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ // Paper start
+ private final CraftScheduler asyncScheduler;
+ private final boolean isAsyncScheduler;
+ public CraftScheduler() {
+ this(false);
+ }
+
+ public CraftScheduler(boolean isAsync) {
+ this.isAsyncScheduler = isAsync;
+ if (isAsync) {
+ this.asyncScheduler = this;
+ } else {
+ this.asyncScheduler = new CraftAsyncScheduler();
+ }
+ }
+ // Paper end
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
@Override
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
public int scheduleSyncDelayedTask(final Plugin plugin, final Runnable task) {
Update CB/S
2018-03-31 11:34:25 +02:00
return this.scheduleSyncDelayedTask(plugin, task, 0L);
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -222,7 +242,7 @@ public class CraftScheduler implements BukkitScheduler {
Update CB/S
2018-03-31 11:34:25 +02:00
} else if (period < CraftTask.NO_REPEATING) {
period = CraftTask.NO_REPEATING;
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
}
- return handle(new CraftAsyncTask(runners, plugin, runnable, nextId(), period), delay);
+ return handle(new CraftAsyncTask(this.asyncScheduler.runners, plugin, runnable, nextId(), period), delay); // Paper
}
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
@Override
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -238,6 +258,11 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
if (taskId <= 0) {
return;
}
+ // Paper start
+ if (!this.isAsyncScheduler) {
+ this.asyncScheduler.cancelTask(taskId);
+ }
+ // Paper end
CraftTask task = runners.get(taskId);
if (task != null) {
task.cancel0();
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -280,6 +305,11 @@ public class CraftScheduler implements BukkitScheduler {
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
@Override
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
public void cancelTasks(final Plugin plugin) {
Validate.notNull(plugin, "Cannot cancel tasks of null plugin");
+ // Paper start
+ if (!this.isAsyncScheduler) {
+ this.asyncScheduler.cancelTasks(plugin);
+ }
+ // Paper end
final CraftTask task = new CraftTask(
new Runnable() {
Update Upstream
2019-05-06 04:58:04 +02:00
@Override
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -319,6 +349,13 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
@Override
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
public boolean isCurrentlyRunning(final int taskId) {
+ // Paper start
Fix isCurrentlyRunning for sync tasks Not sure where this would of ever been used, but for correctness sake.
2018-03-17 18:14:44 +01:00
+ if (!isAsyncScheduler) {
+ if (this.asyncScheduler.isCurrentlyRunning(taskId)) {
+ return true;
+ }
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
+ }
+ // Paper end
final CraftTask task = runners.get(taskId);
Update Upstream
2018-06-21 05:29:33 +02:00
if (task == null) {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
return false;
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -337,6 +374,11 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
if (taskId <= 0) {
return false;
}
+ // Paper start
+ if (!this.isAsyncScheduler && this.asyncScheduler.isQueued(taskId)) {
+ return true;
+ }
+ // Paper end
for (CraftTask task = head.getNext(); task != null; task = task.getNext()) {
if (task.getTaskId() == taskId) {
Update CB/S
2018-03-31 11:34:25 +02:00
return task.getPeriod() >= CraftTask.NO_REPEATING; // The task will run
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -348,6 +390,12 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 9a793cce Remove no longer applicable caveats to setPlayerListName 7137829e SPIGOT-4496: Undeprecate MapView.getId and make int de33ade0 Remove some draft API designations a35fa838 SPIGOT-4472: Add Consumer scheduler methods CraftBukkit Changes: 8cd538e6 SPIGOT-4498: Crash on startup b4ee04ba SPIGOT-4496: Undeprecate MapView.getId and make int ec937d0e SPIGOT-4472: Add Consumer scheduler methods Spigot Changes: a1f2566f Use monotonic time for watchdog bc4adcbf SPIGOT-4498: Crash on startup bb387e6c Rebuild patches
2018-11-24 06:28:04 +01:00
@Override
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
public List<BukkitWorker> getActiveWorkers() {
+ // Paper start
+ if (!isAsyncScheduler) {
+ //noinspection TailRecursion
+ return this.asyncScheduler.getActiveWorkers();
+ }
+ // Paper end
final ArrayList<BukkitWorker> workers = new ArrayList<BukkitWorker>();
for (final CraftTask taskObj : runners.values()) {
// Iterator will be a best-effort (may fail to grab very new values) if called from an async thread
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -385,6 +433,11 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
pending.add(task);
}
}
+ // Paper start
+ if (!this.isAsyncScheduler) {
+ pending.addAll(this.asyncScheduler.getPendingTasks());
+ }
+ // Paper end
return pending;
}
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -392,6 +445,11 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
* This method is designed to never block or wait for locks; an immediate execution of all current tasks.
*/
public void mainThreadHeartbeat(final int currentTick) {
+ // Paper start
+ if (!this.isAsyncScheduler) {
+ this.asyncScheduler.mainThreadHeartbeat(currentTick);
+ }
+ // Paper end
this.currentTick = currentTick;
final List<CraftTask> temp = this.temp;
parsePending();
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -428,7 +486,7 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
parsePending();
} else {
//debugTail = debugTail.setNext(new CraftAsyncDebugger(currentTick + RECENT_TICKS, task.getOwner(), task.getTaskClass())); // Paper
- executor.execute(new ServerSchedulerReportingWrapper(task)); // Paper
+ task.getOwner().getLogger().log(Level.SEVERE, "Unexpected Async Task in the Sync Scheduler. Report this to Paper"); // Paper
// We don't need to parse pending
// (async tasks must live with race-conditions if they attempt to cancel between these few lines of code)
}
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -447,7 +505,7 @@ public class CraftScheduler implements BukkitScheduler {
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
//debugHead = debugHead.getNextHead(currentTick); // Paper
}
- private void addTask(final CraftTask task) {
+ protected void addTask(final CraftTask task) {
final AtomicReference<CraftTask> tail = this.tail;
CraftTask tailTask = tail.get();
while (!tail.compareAndSet(tailTask, task)) {
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -456,7 +514,13 @@ public class CraftScheduler implements BukkitScheduler {
Improved Async Task Scheduler The Craft Scheduler still uses the primary thread for task scheduling. This results in the main thread still having to do work as part of the dispatching of async tasks. If plugins make use of lots of async tasks, such as particle emitters that want to keep the logic off the main thread, the main thread still receives quite a bit of load from processing all of these queued tasks. Additionally, resizing and managing the pending entries for all of these asynchronous tasks takes up time on the main thread too. This commit replaces the implementation of the scheduler when working with asynchronous tasks, by forwarding calls to the new scheduler. The Async Scheduler uses a single thread executor for "management" tasks. The Management Thread is responsible for all adding and dispatching of scheduled tasks. The mainThreadHeartbeat will send a heartbeat task to the management thread with the currentTick value, so that it can find which tasks to execute. Scheduling of an async tasks also dispatches a management task, ensuring that any Queue resizing operation occurs off of the main thread. The async queue uses a complete separate PriorityQueue, ensuring that resize operations are decoupled from the sync tasks queue. Additionally, an optimization was made that if a plugin schedules a single, non repeating, no delay task, that we immediately dispatch it to the executor pool instead of scheduling it. This avoids an unnecessary round trip through the queue, as well as will reduce the size growth of the queue if a plugin schedules lots of asynchronous tasks.
2018-03-17 04:09:51 +01:00
tailTask.setNext(task);
}
- private CraftTask handle(final CraftTask task, final long delay) {
+ protected CraftTask handle(final CraftTask task, final long delay) { // Paper
+ // Paper start
+ if (!this.isAsyncScheduler && !task.isSync()) {
+ this.asyncScheduler.handle(task, delay);
+ return task;
+ }
+ // Paper end
task.setNextRun(currentTick + delay);
addTask(task);
return task;
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -475,8 +539,8 @@ public class CraftScheduler implements BukkitScheduler {
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
return ids.incrementAndGet();
}
- private void parsePending() {
- MinecraftTimings.bukkitSchedulerPendingTimer.startTiming();
+ void parsePending() { // Paper
+ if (!this.isAsyncScheduler) MinecraftTimings.bukkitSchedulerPendingTimer.startTiming(); // Paper
CraftTask head = this.head;
CraftTask task = head.getNext();
CraftTask lastTask = head;
Improve Chunk Prioritization and Internal Scheduler In previous MC versions, we had a rather simple internal scheduler for delayed tasks that would just keep pushing task back until desired tick was reached. The method it called to schedule the task changed behavior in 1.14, and now this scheduler is not working nowhere near what it was supposed to be doing. This was causing long delayed task to eat up CPU (In Oversleep for example) Rewrite this to just use the CraftScheduler for scheduling delayed tasks. Once this was fixed, it became quite clear the code that delayed ticket additions for chunks based on distance was clearly not right, as it was tested on the previous broken logic. So the ticket delay process has been vastly revamped to be even smarter. Chunks behind the player can load slower than the chunks in front of the player. We also can delay ticket adding until one of its neighbors has loaded, as this lets us get a smoother spiral out for the chunks (minus frustum intent). Additionally on frustum previous commit inadvertently broke frustum trying to fix an issue when the real fix lied elsewhere, so restore chunk priority so it works again.
2020-06-09 09:17:25 +02:00
@@ -495,7 +559,7 @@ public class CraftScheduler implements BukkitScheduler {
Updated Upstream (Bukkit/CraftBukkit/Spigot) Upstream has released updates that appears to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing Bukkit Changes: 220bc594 #486: Add method to get player's attack cooldown 21853d39 SPIGOT-5681: Increase max plugin channel size 5b972adc Improve build process b55e58d9 Note which custom generator is missing required method CraftBukkit Changes: 893ad93b #650: Add method to get player's attack cooldown ef706b06 #655: Added support for the VM tag jansi.passthrough when processing messages sent to a ColouredConsoleSender. e0cfb347 SPIGOT-5689: Fireball.setDirection increases velocity too much 94cb030f SPIGOT-5673: swingHand API does not show to self b331a055 SPIGOT-5680: isChunkGenerated creates empty region files e1335932 Improve build process a8ec1d60 Add a couple of method null checks to CraftWorld ce66f693 Misc checkstyle fixes 8bd0e9ab SPIGOT-5669: Fix Beehive.isSedated Spigot Changes: 2040c4c4 SPIGOT-5677, MC-114796: Fix portals generating outside world border ab8f6b5a Rebuild patches e7dc2f53 Rebuild patches
2020-04-27 09:34:45 +02:00
task.setNext(null);
Fix more issues with async scheduler and cancelling pending task was a race condition, so do need to use the head/parsePending logic still
2018-03-17 19:59:03 +01:00
}
this.head = lastTask;
- MinecraftTimings.bukkitSchedulerPendingTimer.stopTiming();
+ if (!this.isAsyncScheduler) MinecraftTimings.bukkitSchedulerPendingTimer.stopTiming(); // Paper
}
private boolean isReady(final int currentTick) {
In neuem Issue referenzieren Permalink kopieren