Actually it touches on both.. PooledByteBufAllocator uses the Recycler as well for “pooling” the ByteBuf container (not the memory it refer to itself tho).
> On 01 Aug 2016, at 19:22, 'Chris Conroy' via Netty discussions > <[email protected]> wrote: > > 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] > <mailto:[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 > <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] <mailto:[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] <mailto:[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] <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On 29 Jul 2016, at 18:51, 'Chris Conroy' via Netty discussions >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> On Fri, Jul 29, 2016 at 12:26 AM, ‘Norman Maurer’ via Netty discussions >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> Comments inside.. >>>> >>>>> On 29 Jul 2016, at 01:10, 'Chris Conroy' via Netty discussions >>>>> <[email protected] <mailto:[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] >>>> <mailto:[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 >>>> <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 >> <https://groups.google.com/d/topic/netty/Ve4lnRvFXjM/unsubscribe>. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] >> <mailto:[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 >> <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] >> <mailto:[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 >> <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] > <mailto:[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 > <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 > <https://groups.google.com/d/topic/netty/Ve4lnRvFXjM/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[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 > <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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/CA%2B%3DgZKCgew6fKDcAg6W1j8t4x0Ta2TzUtCj%3DfSS7WoU9LegNUA%40mail.gmail.com > > <https://groups.google.com/d/msgid/netty/CA%2B%3DgZKCgew6fKDcAg6W1j8t4x0Ta2TzUtCj%3DfSS7WoU9LegNUA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/54A84D87-F7B2-4B66-8DD8-55E4A94CBC0F%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
