.... On 13 February 2011 12:31, Patricia Shanahan <[email protected]> wrote:
> Thanks for looking at the code. > > No worries - concurrency is a favourite topic of mine :) > The original QA failure was non-termination of the removal process. The > test program either gets that or a null pointer exception from a loop near > the start of the head method in FastList. Which I get seems to be very > sensitive to changes in run conditions. I've been mainly getting > non-termination with the latest test program version. > > Either symptom could be due to the same underlying cause, a node that > should be on the list, and either not removed or designated as a "guard" > node, becoming unreachable by following the next chain from the head > pointer. > > The loop in the head method follows the chain forward, unlinking logically > removed non-guard nodes, until it either finds a node that has not been > removed or finds a guard node. Every search has its associated guard node, > and guard nodes are not supposed to get unlinked even if logically removed. > The null pointer failure seems to indicate that at least one node, the guard > node for the failing search, that should be reachable from the head is > disconnected so that the search hits a null next pointer before finding it. > > Mmm, having reviewed the original FastList I was certainly considering the guard code to be the weak area. > I consider the guard node system fragile and over-complicated, and do not > use it in the new version. > > Agreed. > I'll add a more awake write-up of this information to the JIRA ticket later > today. > > That would be good, provides the likes of me with some symptoms to review the old and new code against. > I've been running with the default VM on my Ubuntu VirtualBox > installations: > > Java VM: OpenJDK Client VM (19.0-b09 mixed mode, sharing linux-x86 ) > > I have not done any testing on different VMs, because the existence of even > one widely distributed VM on which it fails is enough. The fact that a > similar test program for the new FastList does not fail suggests that it is > a problem with FastList, not the VM. > > Oh almost certainly old-FastList has a problem.... > Alarmingly, an overnight repeated run of the QA test did not get any > FastList failures, but did get an unrelated NullPointerException from proxy > code called from the test program. > Mmmm, well that might be indicative of a separate problem. However, in respect of the Fast List issue, it's not unusual for a concurrency problem such as this (likely a race condition) to not manifest consistently so....
