This issue is to track the investigation and review of our Recycler usage.
The Recycler was introduced as a light-weight object pool, to reduce GC pressure. We use it in various places, like pooling ByteBuf objects (not the actual memory, just the container), write tasks (When you call write(...) from outside the EventLoop) and many more.
This usage gave us a lot of trouble in the past and also users a hard time when they ended up with a lot of objects in the Reycler due writing to fast etc.
After talking with @Scottmitch we were wondering if most of our usage even make sense, as collecting short-lived objects is very fast and also "cheap" on the JDK these days. Even worse it may hurt GC performance when running longer as we may have more objects ended up in the "old space" of the GC.
Places that come into my mind for those short-lived object that are currently using the Recycler are:
ByteBufAbstractChannelContext.WriteTaskChannelOutboundBuffer.Entry
We should investigate if we may want to remove the Recycler usage for these or remove it completely.
@cconroy for example reported that he not saw any performance differences when disable the recycler via the system property.
@nmittler @Scottmitch @trustin @cconroy @buchgr @ejona86 @belliottsmith WDYT ?
This issue is to track the investigation and review of our Recycler usage.
The Recycler was introduced as a light-weight object pool, to reduce GC pressure. We use it in various places, like pooling ByteBuf objects (not the actual memory, just the container), write tasks (When you call write(...) from outside the EventLoop) and many more.
This usage gave us a lot of trouble in the past and also users a hard time when they ended up with a lot of objects in the Reycler due writing to fast etc.
After talking with @Scottmitch we were wondering if most of our usage even make sense, as collecting short-lived objects is very fast and also "cheap" on the JDK these days. Even worse it may hurt GC performance when running longer as we may have more objects ended up in the "old space" of the GC.
Places that come into my mind for those short-lived object that are currently using the Recycler are:
ByteBufAbstractChannelContext.WriteTaskChannelOutboundBuffer.EntryWe should investigate if we may want to remove the
Recyclerusage for these or remove it completely.@cconroy for example reported that he not saw any performance differences when disable the recycler via the system property.
@nmittler @Scottmitch @trustin @cconroy @buchgr @ejona86 @belliottsmith WDYT ?