I think this article from Trustin explains a bit why buffer pooling was added in Netty 4: https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead
On Fri, Jul 29, 2016 at 7:41 PM, 'Norman Maurer' via Netty discussions < [email protected]> wrote: > I fully agree that if you can operate without object pooling its a lot > “nicer”. > > Like I said I saw problems without it.. That said not sure if the best is > to pool or not pool by default. The problem you are descripted with the > UnpooledBytebufAllocator should be fixed without the need to disable > recycling all together. Like I said I will have a fix soon. > > > On 29 Jul 2016, at 19:38, 'Chris Conroy' via Netty discussions < > [email protected]> wrote: > > Configuration by type could be useful, but so far I’m unable to detect any > performance degradation when leaving the recycler out altogether. Before > adding any more complexity here, I think it would be illuminating to poll > the community of Netty 4 users to see what sorts of workloads, if any, > impact JVM pause time or GC rates. > > Object pooling makes a lot of sense when object setup is expensive. For > example, in my Netty based proxy, I pool Channels since connection setup > (especially with TLS) is an expensive operation. There are definitely > individual circumstances where it may make sense to pool objects without > this characteristic, but it’s usually better to just let the JVM handle > this. After all, an object pool ends up duplicating the same work that the > GC would be doing. > > > On Fri, Jul 29, 2016 at 1:10 PM, 'Norman Maurer' via Netty discussions < > [email protected]> wrote: > >> Also another thing that we considered for a long time was if we should >> have the ability to configure recyclers for different objects differently. >> Like allow to disable them for buffers but still keep for others objects >> etc. >> >> WDYT ? >> >> >> On 29 Jul 2016, at 18:57, Norman Maurer <[email protected]> >> wrote: >> >> >> On 29 Jul 2016, at 18:51, 'Chris Conroy' via Netty discussions < >> [email protected]> wrote: >> >> On Fri, Jul 29, 2016 at 12:26 AM, ‘Norman Maurer’ via Netty discussions < >> [email protected]> wrote: >> >> >> Comments inside.. >>> >>> On 29 Jul 2016, at 01:10, 'Chris Conroy' via Netty discussions < >>> [email protected]> wrote: >>> >>> Ping: What do you think about a global recycler instead of many >>> thread-local recyclers? >>> >>> Im not sure this can be done without too much overhead. But if you want >>> to cook up a PR and show it with benchmarks I would be interested for sure >>> :) >>> >> >> >> >> >> >>> >>> Also, can you provide some more context on the rationale behind the >>> recycler? Especially with the PooledByteBufAllocator, NIO allocations >>> should be very cheap, so why bother to reuse the buffers? >>> >>> Its because of object allocation. It basically reuses the “ByteBuf” >>> container object (non the actual memory here). >>> >> >> >> The ByteBuf objects do pin the NIO memory with an unpooled allocator. >> Are you saying that this is not the case in the pooled allocator? >> >> What you mean here ? In the PooledByteBufAllocator the memory is “pooled” >> separately from the ByteBuf instance. >> >> >> Object allocation is always very cheap. Garbage collection in the eden >> space is incredibly cheap, and most buffers are short-lived. I suspect that >> this may be a premature micro-optimization. I see no difference in JVM >> pause time or GC run rates when I disable the recycler completely. >> >> >> In the past I saw issues because of heavy object allocation (even for >> this short-lived objects). If you not have this issue you could just >> disable the recycler. >> >> >> >> >>> Im working on another fix for the problem you see. And you also may be >>> interested in these: >>> Allow to limit the maximum number of WeakOrderQueue instances per The… >>> <https://github.com/netty/netty/pull/5592> >>> Introduce allocation / pooling ratio in Recycler >>> <https://github.com/netty/netty/pull/5594> >>> Set Recycler DEFAULT_INITIAL_MAX_CAPACITY to a more sane value >>> <https://github.com/netty/netty/pull/5589> >>> Ensure shared capacity is updated correctly when WeakOrderQueue is co… >>> <https://github.com/netty/netty/pull/5577> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Netty discussions" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/netty/CA%2B%3DgZKAKQjw%3DPcqWoYFtKznk6RMtnCDu2G4FP9VAiAug76%2BmTw%40mail.gmail.com >> <https://groups.google.com/d/msgid/netty/CA%2B%3DgZKAKQjw%3DPcqWoYFtKznk6RMtnCDu2G4FP9VAiAug76%2BmTw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Netty discussions" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/netty/Ve4lnRvFXjM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/netty/415234B2-5AED-46CB-AA6E-56C0D34BAFF2%40googlemail.com >> <https://groups.google.com/d/msgid/netty/415234B2-5AED-46CB-AA6E-56C0D34BAFF2%40googlemail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to the Google Groups > "Netty discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/CA%2B%3DgZKDa_Kw5TxyrPAU-g8UZwRyrFkKK-nE9weNPV8-hpM4GUg%40mail.gmail.com > <https://groups.google.com/d/msgid/netty/CA%2B%3DgZKDa_Kw5TxyrPAU-g8UZwRyrFkKK-nE9weNPV8-hpM4GUg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Netty discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/F98F76E5-19B1-4E48-8135-A541562AC60F%40googlemail.com > <https://groups.google.com/d/msgid/netty/F98F76E5-19B1-4E48-8135-A541562AC60F%40googlemail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Netty discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/CAEAdJ9rLwwFWnTBhZebq_%3DpQ%3DrAUSDxEYBDcVeAvmU%3DLyngYMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
