mirror of
https://github.com/PaperMC/Paper.git
synced 2024-12-28 20:07:41 +01:00
c5a10665b8
Spigot still maintains some partial implementation of "tick skipping", a practice in which the MinecraftServer.currentTick field is updated not by an increment of one per actual tick, but instead set to System.currentTimeMillis() / 50. This behaviour means that the tracked tick may "skip" a tick value in case a previous tick took more than the expected 50ms. To compensate for this in important paths, spigot/craftbukkit implements "wall-time". Instead of incrementing/decrementing ticks on block entities/entities by one for each call to their tick() method, they instead increment/decrement important values, like an ItemEntity's age or pickupDelay, by the difference of `currentTick - lastTick`, where `lastTick` is the value of `currentTick` during the last tick() call. These "fixes" however do not play nicely with minecraft's simulation distance as entities/block entities implementing the above behaviour would "catch up" their values when moving from a non-ticking chunk to a ticking one as their `lastTick` value remains stuck on the last tick in a ticking chunk and hence lead to a large "catch up" once ticked again. Paper completely removes the "tick skipping" behaviour (See patch "Further-improve-server-tick-loop"), making the above precautions completely unnecessary, which also rids paper of the previous described incompatibility with non-ticking chunks.
31 lines
1.5 KiB
Diff
31 lines
1.5 KiB
Diff
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
|
From: Aikar <aikar@aikar.co>
|
|
Date: Mon, 4 May 2020 01:08:56 -0400
|
|
Subject: [PATCH] Set cap on JDK per-thread native byte buffer cache
|
|
|
|
See: https://www.evanjones.ca/java-bytebuffer-leak.html
|
|
|
|
This is potentially a source of lots of native memory usage.
|
|
|
|
We are clearly seeing native usage upwards to 1-4GB which doesn't make sense.
|
|
|
|
Region File usage fixed in previous patch should of tecnically only been somewhat
|
|
temporary until GC finally gets it some time later, but between all the various
|
|
plugins doing IO on various threads, this hidden detail of the JDK could be
|
|
keeping long lived large direct buffers in cache.
|
|
|
|
Set system properly at server startup if not set already to help protect from this.
|
|
|
|
diff --git a/src/main/java/org/bukkit/craftbukkit/Main.java b/src/main/java/org/bukkit/craftbukkit/Main.java
|
|
index ed167d0d399924d54d9ff99c10ab8ee093efc149..168cbb239ac5d632908f2b0aca82cbcfdc35651f 100644
|
|
--- a/src/main/java/org/bukkit/craftbukkit/Main.java
|
|
+++ b/src/main/java/org/bukkit/craftbukkit/Main.java
|
|
@@ -27,6 +27,7 @@ public class Main {
|
|
}
|
|
// Paper end
|
|
// Todo: Installation script
|
|
+ if (System.getProperty("jdk.nio.maxCachedBufferSize") == null) System.setProperty("jdk.nio.maxCachedBufferSize", "262144"); // Paper - cap per-thread NIO cache size; https://www.evanjones.ca/java-bytebuffer-leak.html
|
|
OptionParser parser = new OptionParser() {
|
|
{
|
|
this.acceptsAll(Main.asList("?", "help"), "Show the help");
|