Interrupted IO and AWT

Tom Tromey tromey@cygnus.com
Tue Mar 21 09:52:00 GMT 2000


>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> I'm still looking at a scheme that maintains a global,
Hans> non-resizable hash table of locks, with no per-object space for
Hans> locks.

FYI the compiler side of this work has been checked in.
All that remains is the implementation in the runtime.

Hans> Also I suspect that many Java locks are very short-lived.  Thus
Hans> it's important to avoid memory allocation when an object is
Hans> first locked (statistics anyone?).

A paper I read recently suggests that in some situations it is
worthwhile to avoid locks altogether when you can prove that an object
is method- or thread-local ("Escape Analysis for Java", Choi et al --
one of the Jalapeno papers).  In this case we'd need to steal a bit
somewhere (the gc header?) to indicate that the lock should be
avoided.  This is probably even more worthwhile if locks are heavy.

I'm also curious to find literature on how long a Java lock is
typically held (I haven't really looked).  I'm also curious to know
how concerned I should be about the other cases (e.g., if a lock is
held when doing I/O, is this a major concern?  What if it is an
SMP-unfriendly lock?).

Tom


More information about the Java mailing list