Suddenly lots of BrokenBarrierExceptions in a test

After two years, one of my tests (testing some concurrent-db-transaction-stuff) suddenly starts failing with BrokenBarrierException on the build server. It used to work all the time, now it fails one out of three builds. It never fails on the windows work station.

anyone having clues why?

The build server uses this OS: Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005 on a pair of Xenon chips

and this java versi开发者_StackOverflow中文版on: java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)

• eirik

---

I would hazard a guess that the failures are genuine.

The problem with a lot of technically incorrect concurrent code, is that it will work on a large number of implements. The classic example is failing to declare fields as volatile when they need it for visibility, which will usually work on a single-core machine then fail on multi-core machines. However, there are much more subtle bugs that can occur, relying on things such as potential reorderings that are allowed by the JLS but perhaps not implemented in any current JVM implementations.

Chances are there's been a hardware/software upgrade which ought to be trivial but which is now exercising this concurrency problem. Alternatively, there's a small chance that the change in the date is affecting the visibility of the problem (if you use anything like new Date() in your tests, the different value could theoretically cause optimisation to use a slightly different path). Or this could even be down to some other process that used to regularly run on the box stopping; it's entirely possible that HotSpot will look at the CPU utilisation and perform more aggressive optimisations when there's more cycles to spare (I don't think it does do this, in fact, but it could).

Basically, if you have a concurrency problem that's only exposed by some subtle reorderings or optimisations, this may or may not occur depending on the implementation details of the JVM compiler. So installing a new JVM could trigger this, but equally it could be set off by anything that causes the compiler to behave slightly differently.