Clean up implementation and firing of both of these events by routing
both unload and load behaviors to consistent method calls.
This fixes issues where a few places would not call Load or Unload events
when it should have.
Additionally, reduces diff by moving the neighbor marking code into these
consistent points.
Additional benefits of the change include improving the neighbor marking
methods to use getChunkIfLoaded instead of getLoadedChunkAt in some places,
as the latter will cause chunks to be marked active and not unload.
Finally, this also updates CraftWorld.loadChunk to use the new methods, as the
previous logic did not properly handle the new unload queue.
By: Aikar <aikar@aikar.co>
When a chunk is loaded the server tries to ensure it has its initial light
calculations done before sending it to the player. When ticking entities
the server tries to ensure the entity does not walk into an unloaded chunk.
To accomplish these the server checks a one chunk radius around the chunk
to be lit or a two chunk radius around the chunk the entity is in. These
lookups happen every tick even though their result is unlikely to change
that often. To reduce the cost of these checks we replace them with a
system to keep track of what neighbor chunks a chunk has loaded and update
it when chunks load or unload which is a much less frequent action. On a
server with ten players this change removes about 100,000 calls a tick to
LongObjectHashMap's containsKey method.
By: Travis Watkins <amaranth@ubuntu.com>
Currently we use the async chunk loading system only when players trigger
chunk loading. If a chunk is loaded for any other reason it goes through
a separate codepath. This means if a player has trigged a chunk load and
before the chunk loads something else wants the same chunk we will load it
twice and throw away the second result. With this change we instead use
the sync processing feature of the AsynchronousExecutor to load the chunk
which will pull it out of the queue if it was already queued to load. This
means we only ever load a chunk once. Because chunk generation is not
thread safe we still fallback to the vanilla chunk loading system if the
chunk does not currently exist.
By: Travis Watkins <amaranth@ubuntu.com>
When a player triggers a chunk load via walking around or teleporting there
is no need to stop everything and get this chunk on the main thread. The
client is used to having to wait some time for this chunk and the server
doesn't immediately do anything with it except send it to the player. At
the same time chunk loading is the last major source of file IO that still
runs on the main thread.
These two facts make it possible to offload chunks loaded for this reason
to another thread. However, not all parts of chunk loading can happen off
the main thread. For this we use the new AsynchronousExecutor system to
split chunk loading in to three pieces. The first is loading data from
disk, decompressing it, and parsing it in to an NBT structure. The second
piece is creating entities and tile entities in the chunk and adding them
to the world, this is still done on the main thread. The third piece is
informing everyone who requested a chunk load that the load is finished.
For this we register callbacks and then run them on the main thread once
the previous two stages are finished.
There are still cases where a chunk is needed immediately and these will
still trigger chunk loading entirely on the main thread. The most obvious
case is plugins using the API to request a chunk load. We also must load
the chunk immediately when something in the world tries to access it. In
these cases we ignore any possibly pending or in progress chunk loading
that is happening asynchronously as we will have the chunk loaded by the
time they are finished.
The hope is that overall this system will result in less CPU time and
pauses due to blocking file IO on the main thread thus giving more
consistent performance. Testing so far has shown that this also speeds up
chunk loading client side although some of this is likely to be because
we are sending less chunks at once for the client to process.
Thanks for @ammaraskar for help with the implementation of this feature.
By: Travis Watkins <amaranth@ubuntu.com>
