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
