Hi Ulf, This is a regression testcase, there is no performance issue or future refactoring. Please wait for David's comments.
On Sun, Apr 1, 2012 at 7:22 AM, Ulf Zibis <ulf.zi...@gmx.de> wrote: > Hi Sean, > > thanks for your effort. > > Am 31.03.2012 11:43, schrieb Sean Chou: > >> Hi David and Ulf, >> >> The new webrev is at: http://cr.openjdk.java.net/~** >> zhouyx/7121314/webrev.03/<http://cr.openjdk.java.net/~zhouyx/7121314/webrev.03/>< >> http://cr.openjdk.java.net/%**7Ezhouyx/7121314/webrev.03/<http://cr.openjdk.java.net/%7Ezhouyx/7121314/webrev.03/>> >> . >> >> >> About the fix, I remained the previous one. >> About the testcase, I merged the 3 files into one. >> During merging, there are 2 modifications: >> 1. I added static modifier to the 3 classes, which are enclosed by class >> ToArrayTest; >> > You do not need the indirection via main()...run()...test() if you have > all in 1 file. This was only necessary to feature a general usability of > InfraStructure. You can go back to David's 1 + 1 nested class approach > replacing TConcurrentHashMapX by TestCollection and maybe rename realMain() > to test(). > Additionally, loading 4 classes for 1 test would have some performance > impact on the test run, which could be avoided. > > > 2. I removed field TestCollection.fixedSize, which is never read after >> Ulf fixed the bug in testcase. >> > This field would serve to "reset" the TestCollection to fixed default size > without the need of new instantiation for later refactoring or testcase > addition. > > As just discussed before, the doc for setSizeSequence() could be little > more specific: > 71 /* > 72 * Sets the values that size() will return on each use. The > first > 73 * call to size will return sizes[0], then sizes[1] etc. This > 74 * allows us to emulate a concurrent change to the contents of > 75 * the collection without having to perform concurrent changes. > 76 * If sizes[n+1] contains a larger value than on last n-th > invocation, > 77 * the collection will appear to have shrunk when iterated; if > a > 78 * smaller value then the collection will appear to have grown. > 79 * When the last element of sizes is reached, the collection > will > 80 * appear size-fixed. > 81 */ > > > The link to the bug: >> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7121314<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121314> >> The link to the start of the thread: >> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2012-** >> March/009512.html<http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-March/009512.html> >> > Good idea, to repeat these links. > > -Ulf > > -- Best Regards, Sean Chou