Spigot capped it to 2 threads. This bumps it back up to do
maxcores -2 with a max cap of 6.
A typical 4C8T system can use 6 threads and be done in 6 seconds.
Server owners can use system property to override, but this
improves the default.
this should provide a pretty good across-the-board performance
improvement for the entire server, as it's very common for code
to check if (isLoaded(x, z)) { then do something on that chunk }
Previously, containsKey would not read or set the last access cache
By making it do get() != null, we gain the benefits of last access
and also improves thread safey for async isLoaded checks
This exact usage scenario is used in Entity movement, so that alone
saves us up to 5%~ of CPU time for Entity movement.
it used public method instead of private, and moved to world config
also improved the implementation to not use obfuscated stuff
Also removed the Fix Double chest conversion patch since its
fixed in other ways in vanilla
This will provide quite a major performance boost by avoiding
synchronizing on EVERY chunk lookup.
Synchronize, even without contention, incurs processor cache flushes.
Considering this is the 2nd hottest method in the code base, lets
avoid doing that...
Additionally, chunk conversion operations were occuring while
under synchronization which lead to deadlocks.
Now the conversion will occur outside of the lock, and fix
that issue, resolving #1586
Note, that the chunk map is still thread safe for get operations!
The chunk map was never intended to be modified async with our
changes, as we post to main to modify the map, however
we do still synchronize for write operations (put, remove)
We also synchronize for async get operations, ensuring that
async gets are safe.
We do not need to synchronize main thread gets as the processor
cache will be insync since the map is only updated on the main thread.
However, if someone does try to delete or put concurrently, we
will force their operation back to the main thread.
Mojang was not checking that the chunk did not overwrite, or
was successfully removed.
We're seeing odd reports in #1561 that indicates issues around
this are having problems.
1) Get rid of string interning. can be heavy, has been seen to cause issues for some users
2) Use ConcurrentHashMap instead of a SynchronizedMap
3) Stop use of MRUMapCache which is not thread safe for Group lookups
4) Stop using IdentityHashMap which has performance issues in Java 8
Say a player shoots an arrow through a nether portal, the game
would lose the shooter for determining things such as Player Kills,
because the entity is in another world.
If the projectile fails to find the shooter in the current world, check
other worlds.
we've seen some index lines change in length in some PR's, though
this script was suppose to ignore those changes already.
The only way I can see that not working is if the color mode
of grep is breaking the pattern matching, as some people
default their grep to use color=always
this adds color=none to ensure colors are disabled, should ensure it.
If a chunk load comes in on a chunk load or gen thread,
execute it synchronously on that thread instead of enqueueing it.
It doesn't make sense to enqueue it as that thread is then
going to future.join() it and block until it's ready anyways.
This opens risk to a deadlock if every load or gen thread is
waiting on a recursive chunk but it will never finish because
all of the threads are waiting.
If we identify an invalid offset (negative, or the header sectors),
then back up the region file and erase that specific chunks offset
data.
This will avoid crashing the server with AIOBB errors and also avoids
server owners having to consider the entire region file 'lost'.
I'm not sure what leads to this state, I can only assume write cut
off mid bits.
In this scenario, there is absolutely no way to know where the chunk
actually is in the data file without loading every
single chunk in the file. And even to do that, would be quite extreme
due to the fact the file isn't in some orderly fashion.
Since the file is backed up, the user can use a region fixer tool
externally to try to restore that single chunk. We could even
add a command to restore a chunk from a backup file in a different
commit later on. But this at least prevents the server from crashing.
The server will just generate a new chunk and move on,
after printing an error to the console about it.
Also fixed the case reported in this issue about the server
hanging when a corrupt chunk is encountered, so this issue
is now fully closed.
Resolves#1541
Applied a "Only run this when the blocks are different" to
a place, that apparently must be called even with the same
block but different other data I guess.
This was causing oddness with light data.
Chunk Generation was occuring while inside of the progressCache lock
this caused the progressCache to stay blocked for a long period of time
which then blocked main when main needed to clean the expiring map.
We now maintain a separate map for pending scheduler entries, that
we can join on if a 2nd request comes in while one is starting.
This strategy keeps the lock only for a fraction of time but
maintains thread safety.
So now the chunk is generated without holding a lock and wont
block the main thread on the expiring map as we will insert it
once ready.
1) Removed "Regen" mode of Dupe UUID resolver, forced safe.
Some servers who updated before we had safe mode added still had this value.
There's really no reason to keep this mode, as we've seen that vanilla
triggers this often and 99.9999999% of cases will be an actual duplicate
that needs to be deleted.
2) Made Vanilla Debug messages about dupe UUIDs and dupe uuid resolve messages
only show up if the debug.entities flag is on. This will stop server owners
from panicing from seeing these logs, and stop opening bug reports on this,
only for us to tell you "don't worry about it".
3) Avoid adding entities to world that are already added to world.
This can be triggered by anything that causes an entity to be added
to the world during the chunk load process, such as chunk conversions.
Issue #1544 was a case of this.
4) Removed debug warning about ExpiringMap.
Nothing more I know to do about this anyways. We recover from it,
stop warning to reduce noise of issues to us.
This adds a plethora of useful Tags to let you identify common grouping
of materials. This should complete all of the categories that mojang
did not provide official tags for plus some more.
These are not "registered" tags. They are not usable in any form of
command system that might support tags.
These are provided as a Paper maintained list of items so that plugins
do not have to worry about maintaining all these tags themselves.
This API can technically be copy and pasted into a plugin, and plugins
can add additional Tags's if they wish too to their plugin by
instantiating a MaterialSetTag.
This will improve queue times by canceling chunks when a player
leaves the radius of an async loading/generating chunk.
This matches behavior we had pre 1.13 for loading too.
improved the water code so that immunity wont trigger if the entity
has the water pathfinder system active, so this improves support
for all entities that know how to behave in water.
Merged 2 EAR patches together, and removed an MCUtil method that
doesnt have a purpose anymore
Anything that posts something to main thread was not
correctly reporting their errors to the logger, passing the
ExecutionExcetion instead of the cause. This resolves that,
as well as patches some simple cases of System.nanoTime where mojang
had used a LongSupplier to use a different method on client.
This update introduces Entity Activation Range for water mobs.
Activation Range has been one of my biggest performance improvements
I ever added to Minecraft, however "Entity is in Water" is an immunity
case that keeps an entity active.
This update ignores the water check for known water based mobs, allowing
them to actually go inactive.
In addition to that, a new config option was added to spigot.yml to go with
the rest of the entity-activation-range options to let you configure
aquatic mobs like fish, squid and dolphins separately.
This should overall fix all lag caused by water mobs.
These deps were marked as provided, not compile, so they were never
exposed to plugins anyways as we THOUGHT we had done, oops.
Well plugins can still add fastutil to their build and use the
deps as provided by minecraft.
This ensures -api side does not use a deprecated API as fastutil 8
removed the deprecated methods.
Shared Hosts have been concerned over the increased CPU usage that Async Chunks
has introduced. We understand that shared hosts can't allow 1 client
to abuse the systme resources depriving other servers of cpu time, so we've
added some configs to allow hosts to force some settings.
Hosts, you may set the following SYSTEM ENVIRONMENT VARIABLES (NOT JVM FLAGS)
to change some behavior:
PAPER_ASYNC_CHUNKS_SHARED_HOST_GEN=1 - Enable Single Threaded World Generation (capping CPU Usage
PAPER_ASYNC_CHUNKS_SHARED_HOST_GEN=2 - Disable Async Chunk Generation - Please do not do this!!!
- Minecraft is moving towards asynchronousm per-world chunk generation itself. You need to prepare
- for this, so please do not disable async chunk generation.
PAPER_ASYNC_CHUNKS_SHARED_HOST_LOAD=# - Where # is Maximum number of threads to use on Chunk Loading
- This is a max, so your end user can reduce it more too. I suggest no lower than 2. Minimum is 1.
- These are usually much faster request, so outside of loading entire worlds, They usually do not
- get as much load. Paperby default uses CPU Core count * 1.5, so this may default to a higher value
- on shared host and you should override it with this value to say 2-4.
These settings will override your clients paper.yml options. Set as a system wide environment
variable to ensure all Paper clients respect your resource usage desires.
Resolves#1520
This should greatly improve performance by using a No Op lock
while on the main thread.
Vanilla always had a write lock on write operations, but we added
a Read Lock during Async Chunks to make concurrent writes non fatal
for Async Chunks.
This means we added on a bunch of over head to all chunk read operations.
This corrects that, as well as disabling the write lock while on main thread.
It is a general rule that you do not touch a chunk async once it is loaded
into the world, as we never had locks on the chunk before 1.13 even.
So once we are on main, we don't expect concurrent access to begin with,
so we don't need the write locks either.
light calculations repeatedly looks up the same chunk while going
down on the Y access. Pass the chunk to it to skip many round trips
to the map lookup process.
while the gains arent as big since we have last access cache, it
should hopefully avoid many callstacks of depth and improve inlining,
as well as avoids entering a synchronized code block.
The avoiding of entering synchronized section is the main goal here.
Many times I've ran paper test trying to SHUTDOWN
the existing test server, only for it to see that my target folder
is missing (for whatever reason), and it try to build paper to make
the jar exists.
Well, the patch process will wipe out any uncommitted changes, causing
loss of work.
Now we will only build patches if your missing your entire Paper-Server
folder, and only trigger a mvn compile if the jar is missing.
this has technically been a longer standing problem, but if an async
chunk loads after a chunk has been removed from the chunk map, it would
be treated as any other spare chunk and kept loaded until Chunk GC kicks in.
This fixes that, but also obsoletes ChunkGC in that anytime we load a spare
chunk (a chunk outside of any players view distance), we will immediately
mark it for unload.
This should reduce the amount of spare chunks loaded on a server.
The patch was previously applied wrong, and still caused chunk loads.
Now, we will prevent it again, but also added a config option to
disable this optimization.
However, I also updated it so that doors are not removed if the chunk
the door is in is unloaded, so this should avoid breaking farms.
Fixes#1506
Vanilla has some screwy logic that doesn't send a chunk until
it has been post processed. This is an issue as post processing
doesn't occur until all neighbor chunks have been loaded.
This can reduce view distance while generating terrain, but also
cause bugs where chunks are never sent to the client.
This fix always sends chunks to the client, and simply updates
the client anytime post processing is triggered with the new chunk data.
The server does a "Did my update succeed" check after setting
a blocks data to a chunk.
However, writes can not fail outside of a hard error or a
a race condition from multiple threads writing, which is
not something that should ever occur on the server.
So this check is pointless, as if it did occur, the server would
be having data corruption issues anyways.
This provides a small boost to all setType calls.
Vanilla has risk of losing entities by causing them to be
removed from all chunks if they try to move into an unloaded chunk.
This pretty much means high chance this entity will be lost in this scenario.
There is another case that adding an entity to the world can fail if
the chunk isn't loaded.
Lots of the server is designed around addEntity never expecting to fail for these reasons,
nor is it really logical.
This change ensures the chunks are always loaded when entities are
added to the world, or a valid entity moves between chunks.
Hopefully will fix issues #1496 and #1434
The server triggers light recalculations even if the new block
is the same as the old block. At this time, BlockData Properties
do not impact light calculations.
So the only way light should change, is if the block itself
changes from 1 block to another.
Additionally, as of 1.13, water now only blocks 1 light level
instead of 3, meaning that light level decreasing is the same as air.
This means, transitions between water and air also do not need
to recalculate light, which saves a TON of updates caused by
fluids flowing.
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:
39ce5d3a SPIGOT-4399: ItemMeta.equals broken with AttributeModifiers
CraftBukkit Changes:
1cf8b5dc SPIGOT-4400: Populators running on existing chunks
116cb9a1 SPIGOT-4399: Add attribute modifier equality test
5ee1c18a SPIGOT-4398: Set ASM7_EXPERIMENTAL flag
Minecraft is trying to set Dimension Objects based on a Dimension ID
Dimension ID's for custom worlds are dynamically allocate dand not guaranteed
consistent.
This removes checking the NBT data, as the Entity will always have its
DimensionManager set to the world it is being placed into.
This fixes corrupt entities breaking chunk saving in custom worlds.
Upstream has released updates that appears to apply and compile correctly.
This update has been tested to ensure that World Conversion still occurs correctly.
Bukkit Changes:
0812ce2c SPIGOT-4397: isChunkGenerated API
CraftBukkit Changes:
4824655c SPIGOT-4398: Upgrade to ASM 6.2.1 for better Java 11 support
eea43870 MC-134115: Fix issues converting tile entities
1a7f2d10 SPIGOT-4397: isChunkGenerated API
40aed54d SPIGOT-4396: Improve vehicle movement
Spigot Changes:
f6a273b1 Rebuild patches
This restores Asynchronous Chunk Loading to 1.13, as well as adds Asynchronous Chunk Generation..
This provides a massive boost to server performance and should bring 1.13 back closer to 1.12 performance levels for pre generated worlds.
World Generation will now be faster overall than 1.12 since 1.12 did not have async generation.
**DONATE:**
Lots of effort has went into making this happen. Want to say thanks and donate?
https://donate.emc.gs/AsyncChunks
Added information to not use github attachments.
Added information to not report "DO NOT REPORT THIS TO PAPER" logs, because obviously that wasn't clear enough they shouldn't.
light queue is actually buggy, so re-enabling the config.
however, if anyone is ok with the buggy behavior, made the max time lost due to
light queue configurable.
We want to get to making the ligth queue default if we can make it work perfectly.
also applying neighbor optimizations to use the faster method for light checks.
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
CraftBukkit Changes:
dcb43ef8 MC-136886: locate command loads chunks without needing to.
Spigot Changes:
f823ac54 Rebuild patches
There is no reason for the light queue to even be an option. This
enables the light queue for everyone.
This also improves the "can we still tick" time logic to always
check before running a light operation.
previously, we always executed at least 10 on the first world
(but not other worlds...), but we are seeing light take up some
heavy time, so improving that for now.
I've now also improved recheck gaps logic to happen at the end of all single block updates
This also prevents multiple gap checks, as previously if a tick skipped
the gaps check, the next tick would end up re-adding the entry again,
resulting in multiple gap checks.
This now just sets a marker "We need to recheck gaps" and will only occur
once.
This also should reduce chunk loads, as previously, we checked if
the neighbor chunks were loaded for the gap check, however those
neighbor chunks might of unloaded before the light queue operation
actually ran. Now, the neighbor chunk is done when the gap check
is being done, so it should avoid loading chunks.
Fixes#1466Fixes#1431
Some chunks that need conversion may fail the loadChunks pass, and
end up entering the world gen code to finish processing.
We solved this on the API level before, but this needs to apply to
all chunk loads when gen=false
This adds a new Future based, Consumer<Chunk> based, and ability
to control whether or not to generate to the Async Chunk API.
Until Async Chunks merges, these API's are still synchronous, but
this commit will allow plugins to start using the API's in use
with the Async Chunks beta.
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:
cbb4fc16 SPIGOT-1916: Attribute modifiers for ItemStacks
CraftBukkit Changes:
8164f4b2 SPIGOT-1916: Attribute modifiers for ItemStacks
Spigot Changes:
38536abd Rebuild patches
A bug with double chest conversion would lead to data
loss from chunks if they crossed chunk boundries.
This fixes the issue.
It should now be safe to upgrade worlds to 1.13.1
If you try to load a world inresponse to another world loading,
a concurrent modification exception will throw.
This avoids that by making a defensive copy of the list for the server init stage.
you might want to do this if you want to guarantee your world loads
immediately after the vanilla worlds before another plugin has a chance
to load worlds during POST_WORLD plugin stage.
Minecraft moved worlds to a hashmap in 1.13.1.
This creates inconsistent order for iteration of the map.
This patch restores World management to be back as an Array.
.values() will allow us to iterate as it was pre 1.13.1 by
ArrayList, giving consistent ordering and effecient iteration performance.
KeySet and EntrySet iteration is proxied to the List iterator,
and should retain manipulation behavior but nothing should be doing that.
Getting a World by dimension ID is now back a constant time operation.
Hopefully no other plugins try to mess with this map, as we are only handling
known NMS used methods, but we can add more if naughty plugins are found later.
Multiverse was tested with this and no breakage.
Allows you to add to paper.yml
seed-overrides:
world_name: some seed value
This will ignore every where a seed is set/created/loaded and force
a world to use the specified seed.
This seed will end up being saved to the world data file, so it is
a permanent change in that it won't go back if you remove it from paper.yml
It's always been commonly said to 'ignore' that TPS was '19.X', that
it was fine.
I suspect that the inaccuracy of floating point math resulted in us
losing precision over time, making it difficult to actually get back to 20,
as you know the fun 0.1 + 0.1 ... 9 more times != 1 problem.
BigDecimal supports working with doubles with higher precision.
This change makes it so our RollingAverage class maintains all of the data
using BigDecimal and using BigDecimal arithematic operations.
This ensures we have extremely high precision, enabling us to
actually be able print '20 TPS' when TPS is perfect.
computeIfAbsent would leak as the entry
was never registered into the ttl map
This fixes that ,as well as redesigns cleaning to
not run on every manipulation, and instead to run clean
once per tick per expiring map.
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
CraftBukkit Changes:
94b8708a SPIGOT-4373: Item display colours are white by default
61668436 SPIGOT-4378: Fix mistakenly included code
When a mob was about to load a chunk to try to spawn in, we did not
increment the attempt counter, resulting in it being stuck in the mob
spawn loop for a long time and hanging servers.
Found some more unsafe operations in DataFixers.
Also replaced quite a few bad uses of Map.containsKey
containsKey is a common newbie mistake that "reads" cleaner, but
results in double the performance cost of all map operations as
containsKey in MOST cases where null values are not used is identical to get() == null
Considering how deep datafixers go in call stacks, with tons of map lookups,
this micro optimization could provide some gains.
Additionally, many of the containsKey/get/put style operations were
also a concurrency risk, resulting in multiple computation/insertions.
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:
47b9cf30 SPIGOT-4372: LightningStrikeEvent cause API
a9ceda75 Include the plugin channel name in the exception message
CraftBukkit Changes:
a4bdecff SPIGOT-4372: LightningStrikeEvent cause API
34caaf6d SPIGOT-4371: Trident damaged when event cancelled
97315374 SPIGOT-4369: Handle cancelled trident event
bf1c8273 SPIGOT-4370: Remove vehicle if its passenger spawn event was cancelled
Spigot Changes:
6b015b4b SPIGOT-4370: Remove vehicle if its passenger spawn event was cancelled
Modifying of permissions was only half protected, enabling concurrency
issues to occur if permissions were modified async.
While no plugin really should be doing that, modifying operations
are not heavily called, so they are safe to add synchronization to.
Now, all modification API's will be synchronized ensuring safety.
Additionally, hasPermission was victim to a common java newbie mistake
of calling if (containsKey(k)) return get(k), resulting in 2 map lookups.
Optimized it to simply be a single get call cutting permission map
lookups in half.
Aikar