At the time this was re-added, there was concern around how the JIT
would handle the system property that enabled it.
This shouldn't be a problem, and as such we no longer need to block
access to it.
The Vanilla Method Profiler will not provide much to most users however
there is no harm in providing it as an option. For most users, the
recommended and supported method for determining performance issues with
Paper will continue to be Timings.
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.
Zach Brown
Shane Freeder
Aikar