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

AWT multi-threading design appears to be causing performance problems in JDK 1.2

    Details

    • Subcomponent:
    • CPU:
      x86
    • OS:
      generic, windows_nt

      Description

      Licensee states:
      We did an experiment to check on multi-threading
      performance: We ran appletviewer, invoking 2 copies of the GraphLayout
      demo, one copy of the Clock demo, and one copy of the SortDemo. In other
      words, all four applets ran as threads in the same appletviewer process. We
      ran this test on two PentiumPro 200 machines, one with a single CPU and the
      other with two CPUs. We also ran the test under 1.1 and under 1.2. We
      tested to see if the applets would run concurrently and would remain
      responsive to user interaction. All tests were performed using the
      unmodified JDK.

      Our results were that:
      1. the demos ran well and remained responsive on
      both machines under 1.1.
      2. the demos ran noticably more slowly and were less
      responsive on the single-CPU machine under 1.2.
      3. the demos barely ran and were largely
      unresponsive to user input on the dual-CPU machine under 1.2.

      We looked into why this test of concurrency ran so poorly on
      a dual-CPU machine under 1.2. In summary, we found that the problem is heavy
      contention for monitors, which becomes crippling on a dual-CPU box because
      there's real concurrency, hence real contention for system resources.
      Contention is heavy because the applets and the screen updater are doing too
      much inside of synchronized methods.

      We observed two contention scenarios:

      A) Some of the applets do substantial drawing work in
      synchronized methods that are invoked when an AWT event is dispatched. This
      does two things:
      1) it locks the applets' GraphPanels, which the
      applets' other threads are trying to access concurrently, and
      2) it makes the AWT event queue thread wait (without
      holding its monitor). Holding up the event queue thread causes a general lag
      in processing of mouse movement and screen-update events.

      These problems are severe because drawing takes so long.
      When we look at a snapshot of execution, the drawing code is often in the
      Java2d code.

      B) The AWT screen updater thread and the AWT event dispatch
      thread both need access to the same event queue. The screen updater often
      calls Component.coalesceEvents while holding the lock on the queue. This
      causes other threads that are trying to post events to block on the event
      queue monitor.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                serb Sergey Bylokhov
                Reporter:
                jbenoit Jonathan Benoit (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: