DenseIntMap size can become permanently out-of-sync about jvector HOT 5 CLOSED

I think you can get an inconsistency even with two puts?

Thread 1: begin do/while loop
Thread 2: start increasing capacity
T1: add k,v to objects
T2: copy objects [including k, v] to newArray, promote newArray to active objects
T1: stamp is invalid, retry
T1: objects.getAndSet returns non-null, isInsert is false, so we do not increment size

I think we may have to switch to a pessimistic ReadWriteLock which makes me sad.

from jvector.

Possibly we could replace O(1) size() with a combination of

• O(1) isEmpty
• O(1) modificationCount
• O(N) size() (just count the non-null keys)

from jvector.

I'm not sure the two put path works, since t1 retains isInsert to true across retries.

from jvector.

I also considered replacing O(1) size and didn't see a strong reason not to, other than the nagging feeling that we might be able to do something better.

from jvector.

It doesn't look like the difference in optimistic vs pessimistic on put is material, which makes sense b/c build does much more expensive things when adding a new node. So my PR takes that approach to keep things simple.

from jvector.