6b4dbe6207
Motivation: Currently, the recycler max capacity it's only enforced on the thread-local stack which is used when the recycling happens on the same thread that requested the object. When the recycling happens in a different thread, then the objects will be queued into a linked list (where each node holds N objects, default=16). These objects are then transfered into the stack when new objects are requested and the stack is empty. The problem is that the queue doesn't have a max capacity and that can lead to bad scenarios. Eg: - Allocate 1M object from recycler - Recycle all of them from different thread - Recycler WeakOrderQueue will contain 1M objects - Reference graph will be very long to traverse and GC timeseems to be negatively impacted - Size of the queue will never shrink after this Modifications: Add some shared counter which is used to manage capacity limits when recycle from different thread then the allocation thread. We modify the counter whenever we allocate a new Link to reduce the overhead of increment / decrement it. Result: More predictable number of objects mantained in the recycler pool.
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.