This class is designed to be an invisible layer between a normal collection,
and one that silently loses entries because they are only weakly referencable.
Some operations have additional overhead to be semantically correct, but it
maintains the equals contract for all entries, as opposed to identity.
It does not support the equals or hash code method as it cannot easily have
the transitive and commutative properties.
By: Wesley Wolfe <weswolf@aol.com>
This class is a general purpose task execution system, that uses stages
to separate processing blocks for asynchronous and synchronous
executions.
By: Wesley Wolfe <weswolf@aol.com>
This change affects the old chat compatibility layer from an
implementation only standpoint. It does not queue the 'event' to fire,
but rather queues a runnable that allows the calling thread to wait for
execution to finish.
The other effect of this change is that rcon connects now have their
commands queued to be run on next server tick using the same
implementation.
The internal implementation is in org.bukkit.craftbukkit.util.Waitable.
It is very similar to a Future<T> task, but only contains minimal
implementation with object.wait() and object.notify() calls
under the hood of waitable.get() and waitable.run().
PlayerPreLoginEvent now properly implements thread-safe event execution
by queuing the events similar to chat and rcon. This is still a poor way
albeit proper way to implement thread-safety; PlayerPreLoginEvent will
stay deprecated.
By: Wesley Wolfe <weswolf@aol.com>
After further testing it appears that while the original LongHashtable
has issues with object creation churn and is severly slower than even
java.util.HashMap in general case benchmarks it is in fact very efficient
for our use case.
With this in mind I wrote a replacement LongObjectHashMap modeled after
LongHashtable. Unlike the original implementation this one does not use
Entry objects for storage so does not have the same object creation churn.
It also uses a 2D array instead of a 3D one and does not use a cache as
benchmarking shows this is more efficient. The "bucket size" was chosen
based on benchmarking performance of the HashMap with contents that would
be plausible for a 200+ player server. This means it uses a little extra
memory for smaller servers but almost always uses less than the normal
java.util.HashMap.
To make up for the original LongHashtable being a poor choice for generic
datasets I added a mixer to the new implementation based on code from
MurmurHash. While this has no noticable effect positive or negative with
our normal use of chunk coordinates it makes the HashMap perform just as
well with nearly any kind of dataset.
After these changes ChunkProviderServer.isChunkLoaded() goes from using
20% CPU time while sampling to not even showing up after 45 minutes of
sampling due to the CPU usage being too low to be noticed.
By: Travis Watkins <amaranth@ubuntu.com>
Many codepaths only end up with one iterator being used at a time and
most of the rest only get up to two being used so using a static pool of
three is wasteful. This also allows us to efficiently handle cases that
exceed 3 iterators in use. Overall this dramatically increases the hit rate
and results in less iterators being created.
By: Travis Watkins <amaranth@ubuntu.com>
Replace uses of LongHashtable and LongHashset with new implementations.
Remove EntryBase, LongBaseHashtable, LongHashset, and LongHashtable as they
are no longer used.
LongObjectHashMap does not use Entry or EntryBase classes internally for
storage so has much lower object churn and greater performance. LongHashSet
is not as much of performance win for our use case but for general use is
up to seventeen times faster than the old implementation and is in fact
faster than alternatives from "high performance" java libraries. This is
being added so that if someone tries to use it in the future in a place
unrelated to its current use they don't accidentally end up with something
slower than the Java collections HashSet implementation.
By: Travis Watkins <amaranth@ubuntu.com>
Adds a specialized iterator for the list and a pool of iterators to avoid
object churn. Also optimizes the clear() method to reduce object creation.
By: Travis Watkins <amaranth@ubuntu.com>
Added two utility collections for use with PlayerChatEvents allowing lazier
initialization of events and less need to synchronize against the player
list.
Provided a hidden queue system for similar logic to pre-1.3 chat. When a
plugin is listening for the deprecated PlayerChatEvent, all chat will be
delayed to be mirror executed from the main thread. All developers are
encouraged to immediately update to the developmental Bukkit chat API as a
minimum transition for server stability.
Additionally, changes were required to bring thread-safety to the flow
logic. CopyOnWriteArrayList is the only viable means to produce thread
safety with minimal diff; using a sane pre-implemented collection would
require reworking of sections of NMS logic.
As a minor change, implemented expected functionality for
PlayerCommandPreProcessEvent. Setting the player should now change the
player executing the command.
By: Wesley Wolfe <weswolf@aol.com>
JLine 2 allows for better color matching in the console and support for
colors in console on Windows. Hopefully provides better performance as well.
By: EdGruberman <ed@rjump.com>
Make EntityLiving call AI logic every tick again.
Rework PathfinderGoalSelector logic.
Adds UnsafeList for use in places where we use ArrayList and know we won't
get index out of range errors. Added usage to World's tickEntities, Chunk's
entitySlices to speed up searching for entities, and to PathfinderGoalSelector
to speed up dealing with AI goals.
Reworked logic in PathfinderGoalSelector with help from fullwall. This code
no longer uses an extra ArrayList for setting up goals and only updates which
goals should be run every other time it is called.
Removed only calling PathfinderGoalSelector every other tick from EntityLiving
as we now only setup new goals every other tick. This ensures existing goals
run every tick to properly update mob movement.
By: Travis Watkins <amaranth@ubuntu.com>
- All StructureGrowEvent handling for these is in BlockSapling now, using a BlockChangeDelegate to collect the data.
- Moved StructureGrowDelegate into a separate class
By: Zeerix <zeerix@draig.de>
-nojline disables JLine, removes the '>', sets the timestamp to vanilla's and sets the language to English.
-Djline.terminal=jline.UnsupportedTerminal disables JLine and removes the '>'.
By: EvilSeph <evilseph@unaligned.org>
