Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8153267

nmethod's exception cache not multi-thread safe

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b120

      Backports

        Description

        There's a concurrency problem with the nmethod’s exception cache. Readers of the cache may read stale data on weak memory platforms.

        The writers of the cache are synchronized by locks, but there may be concurrent readers: The compiler runtimes use nmethod::handler_for_exception_and_pc to access the cache without locking.
        Therefore, the nmethod's field _exception_cache needs to be volatile and adding new entries must be done by releasing stores. (Loading seems to be fine without acquire because there's an address dependency from the load of the cache to the usage of its contents which is sufficient to ensure ordering on all openjdk platforms.)

        Update:
        JDK-8143897 fixed part of the problem.
        Release should not be strictly required as we have the other barrier, now. It may only produce additional false negatives on weak memory model platforms.
        The _count field gets released, now. But we need acquire for the readers, too.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  mdoerr Martin Doerr
                  Reporter:
                  mdoerr Martin Doerr
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: