This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
RE: Interrupted IO and AWT
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: Interrupted IO and AWT
- From: Tom Tromey <tromey at cygnus dot com>
- Date: Tue, 21 Mar 2000 09:52:16 -0800 (PST)
- Cc: "'Jeff Sturm'" <jsturm at sigma6 dot com>, Tom Tromey <tromey at cygnus dot com>, Bryce McKinlay <bryce at albatross dot co dot nz>, java-discuss at sourceware dot cygnus dot com
- References: <140D21516EC2D3119EE700902787664456E70C@hplex1.hpl.hp.com>
>>>>> "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