river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Progress, and a problem
Date Wed, 22 Dec 2010 03:00:32 GMT
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?


View raw message