I updated the webrev to adjust some tests that a JPRT run reporting as failing:
FAILED: java/util/Map/CheckRandomHashSeed.java FAILED: java/util/Map/TreeBinSplitBackToEntries.java The test TreeBinSplitBackToEntries needs to be revamped as the conditions under which bins are converted to trees and vice versa are no longer hold. Conversion from a bin to a tree will not happen unless the table size is >= 64 (MIN_TREEIFY_CAPACITY) and the number of entries in a bin before adding is >= 7 (TREEIFY_THRESHOLD - 1). Conversion back from a tree to a bin occurs if the number of entries in a tree is <= 6 (UNTREEIFY_THRESHOLD), which AFAICT can occur when the table is resized, but can also occur under remove when the tree size is somewhere between 2 and 6. So we should try and create some tests to trigger this conversion too. Plus tests for traversal when it is known the table contains trees (it is tempting, for convenience, to add instances to Spliterator traversing tests but that is probably overkill) Paul. On Aug 21, 2013, at 2:25 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi, > > Here are Doug's Linked/HashMap changes, discussed in a previous thread, as a > webrev: > > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/ > > I also added some tests related to characteristics associated with fixing > another bug. > > Looking at the diffs will be tricky given there are so many changes. > > > I fixed unchecked warnings in LinkedHashMap, but have not done so for > HashMap, where there are many more casts from Node to TreeNode. One way to > solve that is with a static method: > > @SuppressWarnings("unchecked") > static <K, V> TreeNode<K, V> asTreeNode(Node<K, V> n) { > return (TreeNode<K, V>) n; > } > > but i dunno what the performance implications are. Perhaps it's best to > simply stuff @SuppressWarnings on methods of TreeNode rather than trying to > modify code just for the sake of reducing the scope. > > > A JPRT job has been kicked off. > > I recommend when this code goes in we look closely at code coverage results > to see if we are missing areas testing tree functionality and update/add new > tests accordingly. > > Paul. >
