-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
19
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
In many cases in the JDK, such as Map implementation constructors or Map.putAll implementations, Map.entrySet is called to be simply iterated over without breaks.
This is costly: Map.entrySet's iterator returns a new entry for each next call. This entry is an extra allocation, and would not be easily inlined even with valhalla, as it may refers to the parent map for its ability to update its value in setValue(). In contrast, the forEach call only allocates 1 lambda object for the whole loop.
In addition, the simple for-loop iteration lacks guard against atomic access; for concurrent maps, regular iteration of entrySet may fail spontaneously; meanwhile, the forEach implementations of concurrent map handles such problems gracefully; see https://github.com/openjdk/jdk/blob/d7f31d0d53bfec627edc83ceb75fc6202891e186/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java#L118. A similar case I recall happened in string and string builder in the previous discussions, where functional is used not for performance, but for its safety in concurrency.
This improvement is from https://github.com/openjdk/jdk/pull/7431#discussion_r810671760, in the discussion for the patch forJDK-8281631.
In many cases in the JDK, such as Map implementation constructors or Map.putAll implementations, Map.entrySet is called to be simply iterated over without breaks.
This is costly: Map.entrySet's iterator returns a new entry for each next call. This entry is an extra allocation, and would not be easily inlined even with valhalla, as it may refers to the parent map for its ability to update its value in setValue(). In contrast, the forEach call only allocates 1 lambda object for the whole loop.
In addition, the simple for-loop iteration lacks guard against atomic access; for concurrent maps, regular iteration of entrySet may fail spontaneously; meanwhile, the forEach implementations of concurrent map handles such problems gracefully; see https://github.com/openjdk/jdk/blob/d7f31d0d53bfec627edc83ceb75fc6202891e186/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java#L118. A similar case I recall happened in string and string builder in the previous discussions, where functional is used not for performance, but for its safety in concurrency.
This improvement is from https://github.com/openjdk/jdk/pull/7431#discussion_r810671760, in the discussion for the patch for
- relates to
-
JDK-8281631 HashMap copy constructor and putAll can over-allocate table
- Closed
- links to
-
Review openjdk/jdk/7601