Joern Huxhorn wrote:
So it is a performance enhancement as I guessed. I highly doubt that this will be reverted. I'd more or less expect the other implementations to follow.
After all, this is *not* a bug at all. This behavior, while obviously being extreme, is absolutely in conformance with all documentation. So if it doesn't breach the documentation contract and means a worthwhile performance increase: why switch it back?
Given the highly technical nature of the subject, it is possible that the change went through without anyone noticing its negative effects. Unfortunately, such wide-ranging mistakes happen all the time. As for the argument about no guarantees offered about fairness, while true in letter, it is invalid in spirit. The argument is too punctilious and formalistic. Any developer reading the docs will naturally assume that while there are no guarantees, the synchronization mechanism will not actively impede fairness. In JDK 1.6, the scheduler will systematically favor the thread last holding the lock so that it will always get access to the synchronized resource. Sun calls it biased locking. Biased locking, as introduced in JDK 1.6, will effect thousands of unsuspecting applications. The fact that the bias is intentional does not make it less damaging. It's still a bug. Having said that, I also agree that Sun will not revert to the previous locking behavior anytime soon. I intend to complain about this change as loudly as I can. In the mean time, we'll have to accommodate JDK 1.6 by adopting fair locking primitives as provided by java.util.concurrent.
Regards, Joern.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch