OOM can cause linked array qs to break about jctools HOT 2 CLOSED

I think we can fix the spin loop to read the updated pIndex in the loop so it can recover, or we can take the current size policy and extend it.

<rambling> I'm a little uncomfortable with the recovery logic violating the monotonically increasing property of the indexes. It's a nice property to have, but I can also see the argument that the parity bit is not REALLY an advance in this usecase, we could have used the sign bit for the same purpose and that would have violated monotonic progress just as much.</rambling>

Proposed solution, we follow the size current behaviour here:

size = (cIndex - pIndex)/2 -> queue in transition is empty

=> isEmpty = (cIndex - pIndex)/2 == 0 (make it match size, but without all the funky mitigations)

=> poll/peek loop needs to change:
            long pIndex = lvProducerIndex();
            if (index - pIndex)/2 == 0) return null;
            // poll() == null iff queue is empty, null element is not strong enough indicator, so we must
            // check the producer index. If the queue is indeed not empty we spin until element is
            // visible.
            do
            {
                e = lvRefElement(buffer, offset);
            }
            while (e == null);

from jctools.

Agree: I like the proposed solution and I was thinking about re-reading pIndex every X spin for element as well (very happy we reached the same exact conclusions), although I believe that adding a chunk could be a slow operation (if the allocation is outside a tlab, for example) and being able to promptly return back to the user application code (with a null poll) can help similarly to relaxedPoll to give the application code the chance to do something different (if any).
In short +100 for the proposed solution

from jctools.