Interrupted IO and AWT

Bryce McKinlay
Mon Mar 20 17:48:00 GMT 2000

Per Bothner wrote:

> Rather than write a direct
> Java wrapper for gtk, I'd like us to use the AWT or Swing class
> and method names whenever they match.

I've been considering something similar to this. In addition to exposing
more of the native toolkits functionality to Java code, there's another good
reason reason to create an AWT/Swing-ALIKE API: performance. The AWT is slow
by design due both to the requirements of thread safety and its
event-dispatch queue based design. Because it isn't inherently thread-safe
(and probably never can be), virtually every call into the native peers
needs to be synchronized around a global lock using either either gtk's own
locking or java synchronization. This means calling gtk_threads_enter() and
gtk_threads_leave() inside every native peer method implementation, which no
doubt adds considerable overhead. The other problem is AWT's event-dispatch
queue based design. The native peers exist on a different thread to the
event-dispatch thread, and these communicate using a synchronized queue. For
every event generated by the native peer implementation (every keystroke,
every mouse movement, unmask event, refresh, etc), an event object must be
constructed, and the queue synchronized. The event dispatch thread then
synchronizes with the queue, grabs the oldest event, and calls into user
code to have it processed. The queue lock is always under contention by the
thread(s) putting events onto it and the E.D.T. pulling events off it, and
as we know, locking between native threads is slow. I suspect this is the
major reason why the user-threads based Sun/Borland JDK 1.2.2 performs so
well running JBuilder and other swing apps compared to the other, native
threaded JDKs like IBM 1.1.8 (which by all benchmarks has a much superior
JIT and memory management) - its thread synchronization is 5x or more faster
than linux native locks.

Despite the above problems, I'm still confident that we can do basic,
correct AWT functionality with reasonable performance, mainly because the
lack of JNI overhead will do much to make up for these other things. A good,
working AWT (that can run Swing 1.1) should attract a lot more people to gcj
and show off what can be done with it. I guess the only real way to see how
fast it will be is to implement it and see ;-)

However, by imposing a few restrictions on what can and can't be done wrt
threads and gui calls: like requiring the application to make all gui calls
from one master thread (which, I should point out, Swing already does), and
by having the application call a blocking "EventDispatch.start()" type
method instead of relying on an implicit event dispatch thread, it should be
possible to create an AWT-like API that can expose a lot more native
functionality and is also very fast. By doing this, and by adding swing-like
functionality to it, we would essentially be creating a new toolkit API -
but modeled after the existing ones to ease transition of code to it.

Of course the real solution to the synchronization problem lies in having
better threads support, ie an n:n threading model like Solaris/BeOS/Windows
- but this is something that needs to be done at the glibc/kernel level
rather than in libgcj. Using hybrid/user threads in libgcj would probably
suck because it would be very difficult to make them interact well with
existing native code. The BeOS toolkit for example is very multithreaded and
also very responsive, so it is possible...

> avoid excess helper objects:  We would have a Window, which may
> points to a WindowPeer, which may contain a RawData that points
> to a gtk handle.  What I want to avoid when possible is an additional
> Gtk Java wrapper; whatever class we use to wrap a gtk window
> should implement the WindowPeer interface, without requiring yet
> another class to do so.

Yes, I don't see any reason why there should (usually) be anything other
than AWT object -> peer interface -> Peer implementation object, where the
peer implementation class consists of part java/part native code.


  [ bryce ]

More information about the Java mailing list