In Java 8u141 (1.8.0_141-b15) and newer, the
com.sun.management.HotSpotDiagnostic::dumpHeap API has changed and now
requires all heap dumps to end with the .hprof file extension.
Before this change, servers running 8u141 would be unable to perform a
heap dump.
For more information, please see the official release notes of Java 8
Update 141, linked below.
http://www.oracle.com/technetwork/java/javase/8u141-relnotes-3720385.html
To dump the server heap, run the following command:
`/paper heap`
This is added with the intent that it is useful for administrators and
developers to more easily identify and resolve memory leaks. Both by examining
these dumps themselves and by more easily allowing them to send them to
knowledgable parties.
This is a nearly line-for-line port of the same Sponge feature. So all
credit for the idea and implementation belongs to the that team.
Specifically the following commits:
be08be04b05e10a1b795
763827668e
Was done incorrectly and is now causing level desyncs to client.
Always send current level to the client, and instead make setWindowProperty set the level.
Messages written to System.out are automatically redirected to the
root logger by CraftBukkit. However, before the messages reach the
logger, they are encoded and later decoded again using the standard
system encoding.
On some systems (e.g. FreeBSD), the standard system encoding is
US-ASCII by default, which doesn't support the section sign (§) that
is used for the color codes. Consequently, they will never reach
the formatter that translates them into ANSI escape codes.
There is no reason to write these messages to System.out - it just
adds additional overhead and the encoding problems. We can just log
the messages directly with the root logger.
Adds a Pre Lookup Event and a Post Lookup Event so that plugins may prefill in profile data, and cache the responses from
profiles that had to be looked up.
There is usually no reason to stop reading from the console, so
preventing console input after EOT can be extremely confusing.
To prevent this, we can simply ignore the exception thrown by
JLine and continue reading normally.
It was originally added in Bukkit/CraftBukkit@6aafe7c5a1 as a
workaround for BUKKIT-4956 to fix console output on Windows.
I believe the original issue was related to LOG4J2-965 and fixed
in apache/logging-log4j2@d04659c. Minecraft 1.12 finally updated
the Log4J version so this issue is no longer present.
Console output is still working fine on Windows after removing this.
