Greetings, I have some new diagnostic code that I would like to add to the system that was developed during my hunt for this bug:
8019835 Strings interned in different threads equal but does not == http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019835 https://bugs.openjdk.java.net/browse/JDK-8019835 Here is the third round HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/8019835-webrev/2-hsx25/ Internal: http://javaweb.us.oracle.com/~ddaugher/8019835-webrev/2-hsx25/ This fix was reviewed internally by the following OpenJDK users: rdurbin, sspitsyn, and coleenp. Please note that while this code does detect StringTable corruption due to bad memory, that is not the primary purpose. The primary purpose of the new code is to verify all StringTable invariants. Testing: - JPRT build and test on all platforms with the default value of -XX:VerifyStringTableAtExit set to true - Aurora Adhoc testing on all platforms with product and fastdebug bits with the default value of -XX:VerifyStringTableAtExit set to true - Tested on the system with bad memory named in 8019835 and it nicely shows various types of StringTable corruptions. As always, comments, questions and suggestions are welcome. Dan P.S. Changes between second and third rounds: - removed the redundant code in compare_entries() that Coleen spotted Changes between first and second rounds: - add missing String oop check to StringTable::compare_entries(); only comes into play when an error happens - add mesg_mode parameter to verify_entry() to clarify when we should be supressing duplicate error messages - refactor StringTable::verify_and_compare_entries() into two phases for clarity: - phase 1 verifies all entries in the StringTable - phase 2 compares all entries in the StringTable