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

Excessive CompileTask wait/notify monitor creation

XMLWordPrintable

    • master

      In each CompileTask, there is a Monitor we use to wait/notify blocking task. This is the only use of this monitor. All the coding paths that use it are touching it only when task is blocking.

      When CompileTasks are created during the compilation spike, we end up creating this monitor per CompileTask unnecessarily. This is important for Leyden-like scenarios where we instantiate thousands of CompileTasks without any possibility for free-list reuse.

      We can predicate the lock creation on `is_blocking` to avoid this monitor instantiation.

      Or, we can lift the lock to be shared across multiple CompileTasks. This would cause some superfluous notifications when multiple threads are waiting on blocking compilation, but: a) extra lock work is likely irrelevant at the timescales we spend in compilation; b) it will only, if ever, show up in Xcomp testing; c) in Xcomp, we are effectively running a single blocking thread anyway. This will also turn the lock into proper global lock with relative ranking against MCQ_lock.

      Either of these solutions nicely offset/complement the fix for JDK-8357473.

            shade Aleksey Shipilev
            shade Aleksey Shipilev
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: