That blog post touches on the PooledByteBufAllocator which operates at a level below the Recycler object pool.
On Mon, Aug 1, 2016 at 3:48 AM, Leonardo Gomes <[email protected]> wrote: 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 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/CAEAdJ9rLwwFWnTBhZebq_%3DpQ%3DrAUSDxEYBDcVeAvmU%3DLyngYMQ%40mail.gmail.com > <https://groups.google.com/d/msgid/netty/CAEAdJ9rLwwFWnTBhZebq_%3DpQ%3DrAUSDxEYBDcVeAvmU%3DLyngYMQ%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/CA%2B%3DgZKCgew6fKDcAg6W1j8t4x0Ta2TzUtCj%3DfSS7WoU9LegNUA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
