On Fri, Jul 29, 2016 at 12:57 PM, 'Norman Maurer' via Netty discussions < [email protected]> wrote:
> > On 29 Jul 2016, at 18:51, 'Chris Conroy' via Netty discussions < > [email protected]> wrote: > > 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. > With the unpooled allocator, holding on to `ByteBuf` references causes the corresponding NIO memory to be held for the lifetime of the `ByteBuf`. This is why we exhausted our NIO space with the default settings as the recycler held `ByteBuf`s were taking up all available NIO memory. I haven't tested, but it looks like perhaps this is not the case when using pooled allocation since I don't see any `retain` or `release` calls inside the recycler. > 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. > Yep we can definitely do that. -- 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%3DgZKDOHrH_TWAGbLHHBCcLrF%3DWLVY8U-L1HCK8nMrXzqbHGA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
