Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fix typos after a quick check of the "diffs".

********

Note: Updating the wiki for the upcoming CR7/v2.07/10-for-jdk14 review cycle. Changes have been made, but not yet sanity checked.

********

Table of Contents:

Table of Contents

...

    • inc_om_ref_count() does not implement the "restore obj header" part nor the "save om_ptr in the ObjectMonitorHandle" part mentioned in the previous two subsections.
    • inc_om_ref_count() is used by C2 fast_lock(), C2 fast_unlock() and C2 rtm_inflated_locking() on the LP64 X64 platform.
    • The v2.05 version of C2 fast_lock() has code to detect a deflated and recycled ObjectMonitor after acquiring ownership of the ObjectMonitor. The solution to the race was to drop ownership and take the slow enter path. We have spent a lot of time and energy analyzing this race and the solution to this race and have convinced ourselves that the solution introduces theoretical problems with succession. The proper solution is to switch to using inc_om_ref_count() to protect the ObjectMonitor* for the duration of C2 fast_lock().
    • Robbin wrote a new test called MoCrazy that is targeted at the C2 optimizations. This test revealed a race in the baseline C2 fast_unlock() where ownership was reacquired in order to ensure proper succession. So baseline C2 fast_unlock() had a similar version of the race that we thought we fixed in C2 fast_lock(). The proper solution is to switch to using inc_om_ref_count() to protect the ObjectMonitor* for the duration of C2 fast_unlock().
    • C2 rtm_inflated_locking() is similarly exposed to races with async deflation so inc_om_ref_count() is used to protect the ObjectMonitor* for the duration of C2 rtm_inflated_locking().

...