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] <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 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/415234B2-5AED-46CB-AA6E-56C0D34BAFF2%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
