Although it is not conclusive that PooledByteBufAllocator leaks, it will be very useful to have some information recorded and logged so that we can do some basic sanity checks, such as:
I would add (if not covered under dump diag info) the ability to check number of outstanding references to ByteBuf returned from the pool. Or a PooledbyteBuf implementation that can be used in unit testing which does track the info. This can be useful for unit testing of handlers to ensure a handler doesn't do something silly like;
ByteBuf neverReleased = ctx.alloc().buffer();
or, in addition to above;
neverReleased.release(); //Still 1 reference after this.
and then exits the handler without releasing.
In unit testing the references could at least be checked to see if there are 1 or 0 outstanding ByteBuf references.
I often end up wrapping a ByteBuf with some other object to break out info, so ran into several scenarios of my own stupidity of not releasing things (Now I just implement ReferenceCounted for any object I wrap a bytebuf under to be safe). Also help find nuances such as a CompositeByteBuf doesn't call a retain on buffers added, but will call a release on each ByteBuf.