Hi, Reviewing the code for java.util.HashMap and java.util.Hashtable it struck me that the field modCount should be declared volatile - otherwise a update of the field by another thread might not detected due to a lack of a suitable memory barrier. This apparent omission came to light when comparing the number of classes containing volatile fields between openjdk and classpath. Java-6-openjdk contains 151 classes that contain or extend a class with a volatile field. Classpath 0.97.2 contains only 26 classes that contain a volatile field (0 classes extend a class containing a volatile field). FYI the modCount field in openjdk's HashMap (that performs the same purpose) is declared volatile.
This was discussed on IRC, but just wanted to record here the fact that OpenJDK no longer includes a volatile modifier in the modcount field in java.util.HashMap. This change was committed to the jdk7 mercurial repo a few months ago and I believe the motivation was that the fail-fast behaviour does not provide guarantees and code that accesses HashMap from a single-thread should not pay the price of the volatile read and write.
Closing based on Ismael's comment.