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

JDK-8150134 broke concurrent refinement thread deactivation

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P4 P4
    • None
    • None
    • hotspot
    • gc
    • generic
    • generic

      JDK-8150134 changed the call to DCQS::apply_closure_to_completed_buffer, passing the thread's deactivation threshold as the stop_at argument. The intent was that this would result in the apply_xxx doing nothing and returning false if there aren't at least that many buffers available, and the false return value is used to trigger deactivation.

      Unfortunately, that was based on a mis-understanding of the current meaning of the stop_at parameter. The problem is in DCQS::get_completed_buffer, which contains

        if (_n_completed_buffers <= stop_at) {
          _process_completed = false;
          return NULL;
        }

      With the old green_zone value for stop_at, any concurrent refinement thread would only stop here when the the number of completed buffers fell to green_zone, at which point _process_completed would be set false, which is used by the primary refinement thread to determine whether it should be active.

            kbarrett Kim Barrett
            kbarrett Kim Barrett
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: