d6bf388343
Motivation: If a single Encoder object is promoted to the old generation then every object reachable from the promoted object will eventually be promoted as well. A queue illustrates the problem very well. Say a sequence of inserts and deletions generate an object graph: A -> B -> C -> D -> E -> F -> G -> H, the head of the queue is E, the tail of the queue is H, and A, B, C, D are dead. If all queue nodes are in the young generation, then a young gc will clean up the object graph and leave us with: E -> F -> G -> H on the other hand, if B and C were previously promoted to the old generation, then a young collection assumes the refernece from C to D is from a live object (this is a key result of generational gc, no need to mark the old generation). Hence the young collection assumes the refence to D is a gc root and leave us with the object graph: B-> C -> D -> E -> F -> G -> H. Eventually D, E, F, G, H, and all queue nodes ever seen from this point on will be promoted, regardless of their global live or dead status. It is generally trivial to fix nepotism issues by simply breaking the reference chain after dequeuing a node. Currently Encoder objects do not null their references when removed from the hash map. We have observed a 20X increase in promoted Encoder objects due to nepotism. Modifications: Null before, after, and next fields when removing Encoder objects from maps. Result: Fewer promoted Encoder objects, fewer Encoder objects in the old generation, shorter young collection times, old collections spaced further apart (nepotism is just really bad). Enjoy. |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-http2 | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-socks | ||
| codec-stomp | ||
| codec-xml | ||
| common | ||
| example | ||
| handler | ||
| handler-proxy | ||
| license | ||
| microbench | ||
| resolver | ||
| resolver-dns | ||
| tarball | ||
| testsuite | ||
| testsuite-osgi | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
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.