This looks AWESOME!!! thanks for the contribution, I will have a look at it in the near future and integrate.

@alefedor Can you please open "They also expose another bug that NonBlockingIdentityHashMap.replace fails if there were no such key before.
For example, new NonBlockingIdentityHashMap().replace(1, 0); will throw an AssertionError, because of unexpected null value. I have a strong feeling that a TOMBSTONE should have been there instead." as a separate bug? I'm not sure exactly what you mean here.

@nitsanw Ok. Opened the issue #330

I was curious and tried this test against ConcurrentHashMap, but it fails on JDK16. Any insights on why?

= Invalid execution results =
Init part:
[put(4, 4): null]
Parallel part:
| get(1):    4    | put(1, 4): null |
| remove(1): null | clear():   void |
| get(4):    4    |                 |

Hi @ben-manes !

Nice observation, that's definitely a bug in java.util.concurrent.ConcurrentHashMap.
Sometimes a result of a finishedclear is seen by one read in a parallel thread, but is not seen by the next read.

Deducing from the fact that Lincheck can find this bug in the stress testing mode, but not in the model checking one, I suppose that it is related to weak memory model effects (e.g., missing memory barriers).

Okay, it may also be a feature, not a bug

For aggregate operations
such as {@code putAll} and {@code clear}, concurrent retrievals may
reflect insertion or removal of only some entries.

https://github.com/openjdk/jdk/blob/2ee1f96c14b80b63a29445629b1f2e1caf88e075/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L92

Ahh, that helps explain it then because a backport of CHMv7 also fails in a similar fashion. I was curious about adding the checks to Caffeine which has an asMap() view. Maybe you could advise me off thread about what a good test suite would look like?

@ben-manes

Maybe you could advise me off thread about what a good test suite would look like?

Yes, sure. Email: afedorov2602@gmail.com