Add ReferenceCountUtil.touch(...) calls before we store messages into…

[normanmaurer]

… a queue to make debugging leaks easier

Motivation:

We should touch our messages when we take over ownership, this allows easier debugging of buffer leaks.

Modifications:

Let's add touch call before enqueue into internal datastructure

Result:

Easier to debug buffer leaks

[franz1981]

Why not calling buf.touch directly? It would resolve to a nice invokevirtual instead of interface check and invokeinterface

[normanmaurer]

Why not calling buf.touch directly? It would resolve to a nice invokevirtual instead of interface check and invokeinterface

done

[normanmaurer]

@franz1981 PTAL again

[franz1981]

@normanmaurer

I see there are still touch around; remember #13782 where I've introduced an inlined concrete class check because is in the hot path there?
Given that the paths where is added now are super-hot, I really suggest to make it obvious to the JIT which method we want to call, doing something similar.

I know it's sad we have to perform something like that, but it depends by how many "receivers" (ie different concrete classes) are observed at the instanceof call-site there.
If there is more than one (UnpooledXY, FileRegion, PooledZW) than the JIT has to perform the infamous interface check.
Moreover, invokeinterface right after, has to perform a O(n) scan itself to find the right interface method offset to call it (this instead happens only if there are more than 2 receivers, instead, AFAIK): I've refreshed my knowledge on it at https://blogs.oracle.com/javamagazine/post/mastering-the-mechanics-of-java-method-invocation.

[normanmaurer]

@franz1981

@normanmaurer

I see there are still touch around; remember #13782 where I've introduced an inlined concrete class check because is in the hot path there? Given that the paths where is added now are super-hot, I really suggest to make it obvious to the JIT which method we want to call, doing something similar.

I know it's sad we have to perform something like that, but it depends by how many "receivers" (ie different concrete classes) are observed at the instanceof call-site there. If there is more than one (UnpooledXY, FileRegion, PooledZW) than the JIT has to perform the infamous interface check. Moreover, invokeinterface right after, has to perform a O(n) scan itself to find the right interface method offset to call it (this instead happens only if there are more than 2 receivers, instead, AFAIK): I've refreshed my knowledge on it at https://blogs.oracle.com/javamagazine/post/mastering-the-mechanics-of-java-method-invocation.

Yeah I hink you are right... PTAL again.

[franz1981]

And thanks for the patience @normanmaurer , much appreciated!