On 12/13/2010 10:34 AM, Gregg Wonderly wrote:
This does fail fairly quickly (immediately) on my windows laptop.
I am not sure that I have time to really look over this code. I wonder
if anyone knows if this is relatively new code that John put together as
part of the effort to remove the use of PSE from outrigger, or is the
original "non-persistent" javaspaces implementation?
Perhaps we need to do something different here, a segmented list for
example, which is what PSE did with it's Vector implementation so that
segments of the list could be locked independently, as well as allowing
the segments to be "deleted" from disk once they were "empty".
...
I have an alternative in-memory FIFO FastList implementation,
IterableFastList, which replaces the head and next calls in FastList
with an Iterator.
It has spent the last few hours running the quickly failing test (with
minimal changes to use the new implementation) through 120 passes with
no crashes or dropped nodes. I know exactly why it works, and I plan to
write comments explaining it.
I now need some benchmarks, to both measure its performance and, to the
extent possible given FastList's tendency to crash under stress, compare
it to the current FastList. I'll go ahead and write my own, but anyone
who wants to influence performance tuning in this area might want to add
their benchmarks. If anyone is interested, I'll send them a copy of the
new class.
I expect the main scaling limitation in the new class to be continued
use of synchronization when adding a node, so that the tail pointer and
the next pointer in the old tail node are always updated simultaneously.
If that becomes a significant bottleneck in a JavaSpaces benchmark I'll
work on more aggressive implementations.
Question: Where should I put benchmarks that target a specific
implementation class? In the test/src hierarchy, alongside the JUnit
tests? Does the build process assume that only contains unit tests?
Patricia
