d7fa7be67f
Motivation: There are currently many more places where this could be used which were possibly not considered when the method was added. If https://github.com/netty/netty/pull/8388 is included in its current form, a number of these places could additionally make use of the same BYTE_ARRAYS threadlocal. There's also a couple of adjacent places where an optimistically-pooled heap buffer is used for temp byte storage which could use the threadlocal too in preference to allocating a temp heap bytebuf wrapper. For example https://github.com/netty/netty/blob/4.1/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java#L1417. Modifications: Replace new byte[] with PlatformDependent.allocateUninitializedArray() where appropriate; make use of ByteBufUtil.getBytes() in some places which currently perform the equivalent logic, including avoiding copy of backing array if possible (although would be rare). Result: Further potential speed-up with java9+ and appropriate compile flags. Many of these places could be on latency-sensitive code paths.
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
How to build
For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.
You require the following to build Netty:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.
Branches to look
Development of all versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.
Usage with JDK 9
Netty can be used in modular JDK9 applications as a collection of automatic modules. The module names follow the reverse-DNS style, and are derived from subproject names rather than root packages due to historical reasons. They are listed below:
io.netty.allio.netty.bufferio.netty.codecio.netty.codec.dnsio.netty.codec.haproxyio.netty.codec.httpio.netty.codec.http2io.netty.codec.memcacheio.netty.codec.mqttio.netty.codec.redisio.netty.codec.smtpio.netty.codec.socksio.netty.codec.stompio.netty.codec.xmlio.netty.commonio.netty.handlerio.netty.handler.proxyio.netty.resolverio.netty.resolver.dnsio.netty.transportio.netty.transport.epoll(nativeomitted - reserved keyword in Java)io.netty.transport.kqueue(nativeomitted - reserved keyword in Java)io.netty.transport.unix.common(nativeomitted - reserved keyword in Java)io.netty.transport.rxtxio.netty.transport.sctpio.netty.transport.udt
Automatic modules do not provide any means to declare dependencies, so you need to list each used module separately
in your module-info file.