code review request for more StringTable verification code (8019835)

Daniel D. Daugherty daniel.daugherty at oracle.com
Mon Sep 16 10:08:44 PDT 2013


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


More information about the hotspot-runtime-dev mailing list