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

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.