8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

[Brent Christian]

I'm curious about why this was done:

*** 4452,4462 ****
           public final boolean removeAll(Collection<?> c) {
!             Objects.requireNonNull(c);
               boolean modified = false;
--- 4495,4505 ----
           public final boolean removeAll(Collection<?> c) {
!             if (c == null) throw new NullPointerException();
               boolean modified = false;
*** 4464,4474 ****
           public final boolean retainAll(Collection<?> c) {
!             Objects.requireNonNull(c);
               boolean modified = false;
--- 4507,4517 ----
           public final boolean retainAll(Collection<?> c) {
!             if (c == null) throw new NullPointerException();
               boolean modified = false;


-Brent

On 12/2/13 8:29 AM, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8028564-concurrent-resize/webrev/
>
> This patch is contributed by Doug Lea and fixes two issues found in ConcurrentHashMap:
>
>    1) A problem with concurrent resizes; and
>
>    2) The skipping of elements when traversing through bins that are trees of entries.
>
> Both of these issues can result in elements "disappearing" from the map, either because an update operation such as put failed, or because a contains operation failed to find the entry in the map.
>
> Issue 1) was causing stream tests to fail intermittently on systems with many cores (24 to 32) (furthermore the CHM-based JDK test ToArray was also intermittently failing with less frequency).
>
> After some investigation the cause was distilled down to the use of ConcurrentHashMap in the F/J task used by Stream.forEachOrdered.
>
> Issue 2) was serendipitously reported on concurrentcy-interest just yesterday :-)
>
> Both issues have test cases associated with them that have been tuned to reproduce on systems with low cores i.e. my MacBook!
>
> Paul.
>