Use fast thread local and fix GC nepotism (Fixes #4749)

[franz1981]

Thanks to make the list single linked, fixing GC nepotism is now simpler, but this has forced to remove pollAndExecute
because we need 2 state variables to hold the current head/tail of the task list.

For this same reason, we are forced to define an additional InProgressHead class to keep up to date the current head in order to allow reentrant tasks to keep on being added to the current one.

[franz1981]

mmm looking to the failures I see that probably I'm changing the expected order of execution of tasks, because the reentrant ones are added to be executed next, given them more priority.
I see what going on

[franz1981]

I've fixed the ordering issue: now the tasks are always added in FIFO order

[vietj]

note this will be a problem when we will use Netty 5 and Netty 4

[franz1981]

It will be something to be review, but won't break, because it is still backed by JDK thread local in case the executing thread isn't a fast thread local.

[vietj]

my point is that, this will not be the same Java class in Netty 4 / Netty 5

[franz1981]

Yep, that's a good point indeed...I have a solution that doesn't use any thread locals, but it would complicate a lot the code there, really

[vietj]

yeah but we would need that eventually I think, so perhaps it is best avoiding thread local if we can now that we have the time to do it ?

[franz1981]

I can prepare the a different branch with another version but will use atomic queues to achieve the same, probably with worse performance.
Another version could change a lot the API and pass a queue of existing post actions to let the actions to enqueue themselves but it will super invasive and complex imo.
In the current form this one already deliver what we need Ie avoid ThreadLocal::remove and GC nepotism, so I would prefer to do it in 2 separate steps.
This code is already complex as it is, and bringing more complexity is something that should be weighted with the benefits.

[vietj]

fine

[vietj]

no need to make this class public

[franz1981]

What this pr deliver is to imply that in flight post actions would be queued in FIFO ordering and run when all the existing ones complete, which include additional post actions that can be generated by them.
@vietj any idea if it is what user can expect if compared to the original logic

[vietj]

it does not seem to be an issue to me, to delay all post actions until all actions are executed, perhaps this could work better combined with a max number of actions to execute that we have in another PR ? so we guarantee time execute post actions in a timely manner ?

[vietj]

can you backport the PR to 4.x ?