public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: Interrupted IO and AWT
@ 2000-03-21  9:20 Boehm, Hans
  2000-03-21  9:52 ` Tom Tromey
                   ` (2 more replies)
  0 siblings, 3 replies; 52+ messages in thread
From: Boehm, Hans @ 2000-03-21  9:20 UTC (permalink / raw)
  To: 'Jeff Sturm', Tom Tromey; +Cc: Bryce McKinlay, java-discuss

I'm still planning on looking at this.  But I've been busy with other
things.  (I have a very partial implementation of an alternate locking
scheme, but it's not in any kind of usable shape.  And I'm far less than
100% sure that it will turn out to be the right scheme.)

The rest of this is based on way too few anecdotes, and no real
measurements:

My general impression is that if you don't care much about fairness (and I
suspect we usually don't), spin locks with exponential back-off work quite
well, in that they tend to automatically reduce contention to a reasonable
level.  (It does seem to have the disadvantage that with lots of contention,
you sometimes see individual threads going to very long backoffs.  The net
result is that one or two threads keep the lock for long periods, thus
reducing the need to move the cache line back and forth.  This is probably
the right thing for throughput, but not fairness.)  I tend to implement
short backoff intervals as spins, and longer ones using some sort of sleep
primitive.

For some strange reason, that's a scheme that's rarely discussed in the
literature.  Does anyone have some real measurements that include something
like this scheme?

I'm still looking at a scheme that maintains a global, non-resizable hash
table of locks, with no per-object space for locks.  (Collisions do force
memory allocation.)  My impression is that shrinking objects is very
worthwhile, since it increases the effectiveness of the cache, and decreases
memory bandwidth requirements.  Also I suspect that many Java locks are very
short-lived.  Thus it's important to avoid memory allocation when an object
is first locked (statistics anyone?).  Again this probably favors throughput
over predictability, fairness, etc.  But fairness doesn't help much if the
throughput goes to zero.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:10 AM
To: Tom Tromey
Cc: Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21  9:20 Interrupted IO and AWT Boehm, Hans
@ 2000-03-21  9:52 ` Tom Tromey
  2000-03-21 12:31   ` Jeff Sturm
  2000-04-01  0:00   ` Tom Tromey
  2000-03-21 12:17 ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  2 siblings, 2 replies; 52+ messages in thread
From: Tom Tromey @ 2000-03-21  9:52 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Jeff Sturm', Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  9:20 Interrupted IO and AWT Boehm, Hans
  2000-03-21  9:52 ` Tom Tromey
@ 2000-03-21 12:17 ` Jeff Sturm
  2000-03-21 13:30   ` Tom Tromey
  2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  2 siblings, 2 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-03-21 12:17 UTC (permalink / raw)
  To: Boehm, Hans; +Cc: Tom Tromey, Bryce McKinlay, java-discuss

"Boehm, Hans" wrote:
> My general impression is that if you don't care much about fairness (and I
> suspect we usually don't), spin locks with exponential back-off work quite
> well, in that they tend to automatically reduce contention to a reasonable
> level.  (It does seem to have the disadvantage that with lots of contention,
> you sometimes see individual threads going to very long backoffs.  The net
> result is that one or two threads keep the lock for long periods, thus
> reducing the need to move the cache line back and forth.  This is probably
> the right thing for throughput, but not fairness.)  I tend to implement
> short backoff intervals as spins, and longer ones using some sort of sleep
> primitive.

A very large number of locks are extremely short duration, in my
experience.  It makes sense to just spin on them... since the
probability of contention approaches zero as the duration shrinks,
fairness may be of negligible concern for locks that cover just a few
instructions.  This is especially true of a uniprocessor, in which
contention only takes place if a thread is preempted within a critical
section.

Even on SMP, there is no value to using suspend/resume on a thread that
will claim the lock just as fast by spinning, if the duration is much
less than a millisecond there's little chance the spinning processor
could have done any useful work anyway, given the overhead of system
calls and context switching.

Unfortunately Java supports just one synchronization primitive which
must behave reasonably in all scenarios, even if (e.g.) a thread blocks
on I/O.  But large portions of libgcj are C++, in which case we have
more options.  All critical sections in libgcj are currently handled
with _Jv_MonitorEnter/_Jv_MonitorExit, (outside of boehm-gc, which
relies on a local spinlock implementation).  There may be room for
improvement there.

> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

> I'm still looking at a scheme that maintains a global, non-resizable hash
> table of locks, with no per-object space for locks.  (Collisions do force
> memory allocation.)  My impression is that shrinking objects is very
> worthwhile, since it increases the effectiveness of the cache, and decreases
> memory bandwidth requirements.  Also I suspect that many Java locks are very
> short-lived.  Thus it's important to avoid memory allocation when an object
> is first locked (statistics anyone?).  Again this probably favors throughput
> over predictability, fairness, etc.  But fairness doesn't help much if the
> throughput goes to zero.

Sounds interesting.

In the Java code we develop, I consider long-term synchronization blocks
a bug, and favor rewriting them using a Mutex implementation we have
based on Doug Lea's concurrent package.  By keeping synchronized blocks
short we can tune the algorithm (whenever possible) and avoid deadlock
conditions.  Our Mutex class has some deadlock detection built in. 
OTOH, deadlocks around Java monitors are easy to produce and extremely
difficult to debug.

That's not to say our code is typical... I fear that long synchronized
blocks are common in Java code because that is the path of least
resistance.  Coarse-grained locking simply takes more work.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  9:52 ` Tom Tromey
@ 2000-03-21 12:31   ` Jeff Sturm
  2000-03-21 12:39     ` Per Bothner
                       ` (2 more replies)
  2000-04-01  0:00   ` Tom Tromey
  1 sibling, 3 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-03-21 12:31 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Boehm, Hans, Bryce McKinlay, java-discuss

Tom Tromey wrote:
> 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.

Surely the compiler could detect this in some cases... are you saying it
could be detected at runtime as well?

Tom, I think you mentioned once the use of locks for Java string
concatenation:

String f(int i) {
  return "f(" + i + ") called";
}

That method will normally do a monitorenter/monitorexit twice.  Lock
avoidance may eliminate the useless locks in string contentation
completely.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:31   ` Jeff Sturm
@ 2000-03-21 12:39     ` Per Bothner
  2000-04-01  0:00       ` Per Bothner
  2000-03-21 13:23     ` Tom Tromey
  2000-04-01  0:00     ` Jeff Sturm
  2 siblings, 1 reply; 52+ messages in thread
From: Per Bothner @ 2000-03-21 12:39 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Tom, I think you mentioned once the use of locks for Java string
> concatenation:
> 
> String f(int i) {
>   return "f(" + i + ") called";
> }
> 
> That method will normally do a monitorenter/monitorexit twice.  Lock
> avoidance may eliminate the useless locks in string contentation
> completely.

That is certainly a special case we can do by just having the compiler
emit non-locking calls.  That should be straight-forward to fix.

We can also "inline" the StringBuffer on the stack (though not
necessarily the buffer's data, of course), by using a special
(non-Java) C++ class.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:31   ` Jeff Sturm
  2000-03-21 12:39     ` Per Bothner
@ 2000-03-21 13:23     ` Tom Tromey
  2000-04-01  0:00       ` Tom Tromey
  2000-04-01  0:00     ` Jeff Sturm
  2 siblings, 1 reply; 52+ messages in thread
From: Tom Tromey @ 2000-03-21 13:23 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Tom Tromey, Boehm, Hans, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Surely the compiler could detect this in some cases... are you
Jeff> saying it could be detected at runtime as well?

The compiler can detect it, but my understanding is that in some
situations you must dynamically mark the object to get the real
benefit.  It's probable I misunderstood the paper, though.

Jeff> Tom, I think you mentioned once the use of locks for Java string
Jeff> concatenation:

Yeah, but this is one we should do preemptively -- it might be a while
before we implement stack allocation &c in the compiler, but for this
we can just generate calls to a non-locking StringBuffer analogue.
Unfortunately this has been pretty low priority.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:17 ` Jeff Sturm
@ 2000-03-21 13:30   ` Tom Tromey
  2000-04-01  0:00     ` Tom Tromey
  2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 1 reply; 52+ messages in thread
From: Tom Tromey @ 2000-03-21 13:30 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Boehm, Hans, Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 13:23     ` Tom Tromey
@ 2000-04-01  0:00       ` Tom Tromey
  0 siblings, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Tom Tromey, Boehm, Hans, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Surely the compiler could detect this in some cases... are you
Jeff> saying it could be detected at runtime as well?

The compiler can detect it, but my understanding is that in some
situations you must dynamically mark the object to get the real
benefit.  It's probable I misunderstood the paper, though.

Jeff> Tom, I think you mentioned once the use of locks for Java string
Jeff> concatenation:

Yeah, but this is one we should do preemptively -- it might be a while
before we implement stack allocation &c in the compiler, but for this
we can just generate calls to a non-locking StringBuffer analogue.
Unfortunately this has been pretty low priority.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21  9:20 Interrupted IO and AWT Boehm, Hans
  2000-03-21  9:52 ` Tom Tromey
  2000-03-21 12:17 ` Jeff Sturm
@ 2000-04-01  0:00 ` Boehm, Hans
  2 siblings, 0 replies; 52+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Jeff Sturm', Tom Tromey; +Cc: Bryce McKinlay, java-discuss

I'm still planning on looking at this.  But I've been busy with other
things.  (I have a very partial implementation of an alternate locking
scheme, but it's not in any kind of usable shape.  And I'm far less than
100% sure that it will turn out to be the right scheme.)

The rest of this is based on way too few anecdotes, and no real
measurements:

My general impression is that if you don't care much about fairness (and I
suspect we usually don't), spin locks with exponential back-off work quite
well, in that they tend to automatically reduce contention to a reasonable
level.  (It does seem to have the disadvantage that with lots of contention,
you sometimes see individual threads going to very long backoffs.  The net
result is that one or two threads keep the lock for long periods, thus
reducing the need to move the cache line back and forth.  This is probably
the right thing for throughput, but not fairness.)  I tend to implement
short backoff intervals as spins, and longer ones using some sort of sleep
primitive.

For some strange reason, that's a scheme that's rarely discussed in the
literature.  Does anyone have some real measurements that include something
like this scheme?

I'm still looking at a scheme that maintains a global, non-resizable hash
table of locks, with no per-object space for locks.  (Collisions do force
memory allocation.)  My impression is that shrinking objects is very
worthwhile, since it increases the effectiveness of the cache, and decreases
memory bandwidth requirements.  Also I suspect that many Java locks are very
short-lived.  Thus it's important to avoid memory allocation when an object
is first locked (statistics anyone?).  Again this probably favors throughput
over predictability, fairness, etc.  But fairness doesn't help much if the
throughput goes to zero.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:10 AM
To: Tom Tromey
Cc: Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:17 ` Jeff Sturm
  2000-03-21 13:30   ` Tom Tromey
@ 2000-04-01  0:00   ` Jeff Sturm
  1 sibling, 0 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Boehm, Hans; +Cc: Tom Tromey, Bryce McKinlay, java-discuss

"Boehm, Hans" wrote:
> My general impression is that if you don't care much about fairness (and I
> suspect we usually don't), spin locks with exponential back-off work quite
> well, in that they tend to automatically reduce contention to a reasonable
> level.  (It does seem to have the disadvantage that with lots of contention,
> you sometimes see individual threads going to very long backoffs.  The net
> result is that one or two threads keep the lock for long periods, thus
> reducing the need to move the cache line back and forth.  This is probably
> the right thing for throughput, but not fairness.)  I tend to implement
> short backoff intervals as spins, and longer ones using some sort of sleep
> primitive.

A very large number of locks are extremely short duration, in my
experience.  It makes sense to just spin on them... since the
probability of contention approaches zero as the duration shrinks,
fairness may be of negligible concern for locks that cover just a few
instructions.  This is especially true of a uniprocessor, in which
contention only takes place if a thread is preempted within a critical
section.

Even on SMP, there is no value to using suspend/resume on a thread that
will claim the lock just as fast by spinning, if the duration is much
less than a millisecond there's little chance the spinning processor
could have done any useful work anyway, given the overhead of system
calls and context switching.

Unfortunately Java supports just one synchronization primitive which
must behave reasonably in all scenarios, even if (e.g.) a thread blocks
on I/O.  But large portions of libgcj are C++, in which case we have
more options.  All critical sections in libgcj are currently handled
with _Jv_MonitorEnter/_Jv_MonitorExit, (outside of boehm-gc, which
relies on a local spinlock implementation).  There may be room for
improvement there.

> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

> I'm still looking at a scheme that maintains a global, non-resizable hash
> table of locks, with no per-object space for locks.  (Collisions do force
> memory allocation.)  My impression is that shrinking objects is very
> worthwhile, since it increases the effectiveness of the cache, and decreases
> memory bandwidth requirements.  Also I suspect that many Java locks are very
> short-lived.  Thus it's important to avoid memory allocation when an object
> is first locked (statistics anyone?).  Again this probably favors throughput
> over predictability, fairness, etc.  But fairness doesn't help much if the
> throughput goes to zero.

Sounds interesting.

In the Java code we develop, I consider long-term synchronization blocks
a bug, and favor rewriting them using a Mutex implementation we have
based on Doug Lea's concurrent package.  By keeping synchronized blocks
short we can tune the algorithm (whenever possible) and avoid deadlock
conditions.  Our Mutex class has some deadlock detection built in. 
OTOH, deadlocks around Java monitors are easy to produce and extremely
difficult to debug.

That's not to say our code is typical... I fear that long synchronized
blocks are common in Java code because that is the path of least
resistance.  Coarse-grained locking simply takes more work.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:39     ` Per Bothner
@ 2000-04-01  0:00       ` Per Bothner
  0 siblings, 0 replies; 52+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Tom, I think you mentioned once the use of locks for Java string
> concatenation:
> 
> String f(int i) {
>   return "f(" + i + ") called";
> }
> 
> That method will normally do a monitorenter/monitorexit twice.  Lock
> avoidance may eliminate the useless locks in string contentation
> completely.

That is certainly a special case we can do by just having the compiler
emit non-locking calls.  That should be straight-forward to fix.

We can also "inline" the StringBuffer on the stack (though not
necessarily the buffer's data, of course), by using a special
(non-Java) C++ class.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 13:30   ` Tom Tromey
@ 2000-04-01  0:00     ` Tom Tromey
  0 siblings, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Boehm, Hans, Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21  9:52 ` Tom Tromey
  2000-03-21 12:31   ` Jeff Sturm
@ 2000-04-01  0:00   ` Tom Tromey
  1 sibling, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Jeff Sturm', Tom Tromey, Bryce McKinlay, java-discuss

>>>>> "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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 12:31   ` Jeff Sturm
  2000-03-21 12:39     ` Per Bothner
  2000-03-21 13:23     ` Tom Tromey
@ 2000-04-01  0:00     ` Jeff Sturm
  2 siblings, 0 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Boehm, Hans, Bryce McKinlay, java-discuss

Tom Tromey wrote:
> 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.

Surely the compiler could detect this in some cases... are you saying it
could be detected at runtime as well?

Tom, I think you mentioned once the use of locks for Java string
concatenation:

String f(int i) {
  return "f(" + i + ") called";
}

That method will normally do a monitorenter/monitorexit twice.  Lock
avoidance may eliminate the useless locks in string contentation
completely.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:25                 ` Per Bothner
  2000-03-21 14:21                   ` Paul Fisher
@ 2000-04-01  0:00                   ` Per Bothner
  1 sibling, 0 replies; 52+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> I don't believe it would be feasible to actually implement Swing using
> GTK+ or Qt (for example, directly mapping the Swing tree widget to
> GTK+'s tree widget).  However, I've often thought about this
> possibility; it's certainly appealing.

One of the fundamental ideas of Swing is the separation of "model"
and "view+controller".  For example two JTextPanes can both be using the
same Document.  How suitable are gtk widgets for doing things like that?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Interrupted IO and AWT
  2000-03-20  6:19     ` Interrupted IO and AWT Jon Beniston
  2000-03-20  7:07       ` Jeff Sturm
  2000-03-20  8:22       ` Tom Tromey
@ 2000-04-01  0:00       ` Jon Beniston
  2 siblings, 0 replies; 52+ messages in thread
From: Jon Beniston @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Hi,

I seem to recall reading somewhere on Sun's Bug list that the interrupting
of IO has in some form been deprecated. Does any one know whether this is
the case? I ask, because I'm wondering whether I should implement this in
the Win32 port. It seems as if there may be some overhead. Would this be
worth it it the general case? Personally, I've never made use of it.

Secondly, I'm quite interested in doing some work on implementing AWT (I'm
more intrested in Client stuff myself). I was wondering if someone could
clear up the position of this, esp. regarding the Classpath merger. I seem
to recall that everything from Classpath is available except the AWT code.
Now is this all AWT code or just the native implementation? IF I do use it
what is the final result? That the executable is cover by the GPL? I can
live with that for now...

Jon Beniston.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 17:48                 ` Bryce McKinlay
  2000-03-21  7:18                   ` Tom Tromey
@ 2000-04-01  0:00                   ` Bryce McKinlay
  1 sibling, 0 replies; 52+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

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.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21 20:49 ` Jeff Sturm
@ 2000-04-01  0:00   ` Jeff Sturm
  0 siblings, 0 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Tom Tromey', Jeff Sturm, Bryce McKinlay, java-discuss

On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com


^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:09               ` Paul Fisher
  2000-03-20 13:25                 ` Per Bothner
@ 2000-04-01  0:00                 ` Paul Fisher
  1 sibling, 0 replies; 52+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Let's say somebody wants to use gcj to write desktop apps for KDE or
> Gnome.  How would they best proceed?

Currently, using the standard Java AWT API is their best bet, with the
GTK+ Peer libraries from Classpath.  There's also the `java-gnome'
project <URL: http://www.lirmm.fr/~gutkneco/devpt/javagnome.html >,
which provides Java bindings for the GTK+ and Gnome APIs.

I read somewhere recently that the KDE project has started work on a
set of Qt AWT peers, but I don't have a URL handy.

> The PLAF's are a bad idea because they don't leverage a native
> toolkit, they attempt to reimplement it in Java.

There's no reason why a Swing PLAF couldn't be written that does
leverage the native toolkit.  (A GTK+ Swing PLAF is on the TODO list
for Classpath).

> AWT isn't so good either because it doesn't leverage much of the
> capability of good toolkits out there... e.g. there is no tree
> widget or image button in AWT.

Strictly speaking, it's permissible for getGraphics to return a valid
Graphics object for any Component.  The peer side, however, is only
required to return a valid Graphics object for Canvas and Container.
So, it is possible (and legal) to doodle on random widgets, assuming
the peer implementation supports it.

> Then implement AWT and (possibly) Swing atop this native API to be
> compatibile with other Java applications.

Swing, by design, only depends on the basic drawing primitives of the
AWT.

I don't believe it would be feasible to actually implement Swing using
GTK+ or Qt (for example, directly mapping the Swing tree widget to
GTK+'s tree widget).  However, I've often thought about this
possibility; it's certainly appealing.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42             ` Jeff Sturm
                                 ` (2 preceding siblings ...)
  2000-03-20 13:17               ` Per Bothner
@ 2000-04-01  0:00               ` Jeff Sturm
  3 siblings, 0 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:
> The two approaches have different trade-offs:
> - Native peers can probably be implemented faster than a Swing-like
> solution.

To my knowledge there exist no free or third-party implementations of
Swing.  It could be extremely difficult to do.

> - Native peers may have better compatibility (both look-and-feel and
> programming-wise) than pure Java widgets.

Especially if a toolkit (i.e. GTK+) is used.  It's also possible to
write native peers using Xlib or Win32/GDI directly... though this leads
to the same interoperability problems as Swing.

(Sun never really got this part right.  AWT applications on Linux don't
look right because Sun used the archaic Motif toolkit.  Early versions
of the Win32 JDK did use MFC to inherit a certain amount of Win32
behavior, but that was later scrapped for direct window/graphics calls.)

> - Pure Java widgets allow compatibility with Swing's "pluggable-
> look-and-feel" (PLAF).  However, I'm not sure that is important.
> I would rather have PLAF built using (say) gtk's theability.

Me too.

Let's say somebody wants to use gcj to write desktop apps for KDE or
Gnome.  How would they best proceed?  Swing is not a good fit because
apps written in Swing tend to look like, umm, Swing.  The PLAF's are a
bad idea because they don't leverage a native toolkit, they attempt to
reimplement it in Java.  Consequently Swing PLAFs are both difficult to
write and imperfect in their emulation.

AWT isn't so good either because it doesn't leverage much of the
capability of good toolkits out there... e.g. there is no tree widget or
image button in AWT.

I'd like to see real Java bindings in GTK and/or KDE so developers can
write first class Java apps for those environments.  Then implement AWT
and (possibly) Swing atop this native API to be compatibile with other
Java applications.

To me this is consistent with the apparent philosophy of the gcj
project: remain compatible with Java but innovate where appropriate. 
Gcj has already innovated with CNI.

(Those who are in the "pure Java" camp will likely disagree with me.  My
aim is not to compromise Java compatibility, but extend its reach to
application domains where it has flopped, like desktop programming.)


-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:51               ` Tom Tromey
@ 2000-04-01  0:00                 ` Tom Tromey
  0 siblings, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Per Bothner, java-discuss

Jeff> I'd like to see real Java bindings in GTK and/or KDE so developers can
Jeff> write first class Java apps for those environments.  Then implement AWT
Jeff> and (possibly) Swing atop this native API to be compatibile with other
Jeff> Java applications.

I believe there is a Java/Gnome effort, which provides Java bindings
for Gtk and Gnome.  I haven't looked to see how hard it would be to
make it work with gcj.

I think this is a reasonable approach as well.  We still need AWT and
Swing for compatibility and for people who want to write "Java
portable" applicatoins.

This also opens up the possibly weird capability of writing a pure
Java AWT on top of the Java Gtk package.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  7:18                   ` Tom Tromey
  2000-03-21  8:06                     ` Jeff Sturm
@ 2000-04-01  0:00                     ` Tom Tromey
  1 sibling, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: Per Bothner, java-discuss

Bryce> The queue lock is always under contention by the thread(s)
Bryce> putting events onto it and the E.D.T. pulling events off it,
Bryce> and as we know, locking between native threads is slow. I
Bryce> suspect this is the major reason why the user-threads based
Bryce> Sun/Borland JDK 1.2.2 performs so well running JBuilder and
Bryce> other swing apps compared to the other, native threaded JDKs
Bryce> like IBM 1.1.8 (which by all benchmarks has a much superior JIT
Bryce> and memory management) - its thread synchronization is 5x or
Bryce> more faster than linux native locks.

Sometimes I wonder if we should have two locking implementations, one
as fast as possible and one that is perhaps slower but SMP friendly.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21 16:05 Boehm, Hans
  2000-03-21 20:49 ` Jeff Sturm
@ 2000-04-01  0:00 ` Boehm, Hans
  1 sibling, 0 replies; 52+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Tom Tromey', Jeff Sturm; +Cc: Bryce McKinlay, java-discuss

It seems to me that a spin lock with exponential back-off (and sleeps for
longer wait times) doesn't behave that badly, even in this case.  There'll
be some unneeded wakeups on the part of the waiting thread near the
beginning, and it may sleep for up to about twice as long as it should
(assuming the base of the exponential is 2).  Clearly this is suboptimal in
this case.  But are there cases in which it's a serious problem?

Hans 

-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Tuesday, March 21, 2000 1:30 PM
To: Jeff Sturm
Cc: Boehm, Hans; Tom Tromey; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:17               ` Per Bothner
  2000-03-20 17:48                 ` Bryce McKinlay
@ 2000-04-01  0:00                 ` Per Bothner
  1 sibling, 0 replies; 52+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> To my knowledge there exist no free or third-party implementations of
> Swing.  It could be extremely difficult to do.

I know.  My recommendation is to write a subset of Swing (and AWT), and
enhancing it as people feel motivated.

> I'd like to see real Java bindings in GTK and/or KDE so developers can
> write first class Java apps for those environments.  Then implement AWT
> and (possibly) Swing atop this native API to be compatibile with other
> Java applications.

I agree with one slight modification:  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.  The main thing is I want to
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.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:21         ` Tom Tromey
  2000-03-20 10:30           ` Per Bothner
@ 2000-04-01  0:00           ` Tom Tromey
  1 sibling, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Jon Beniston, java-discuss

Jeff> If I had my choice, interruptable I/O would be a configure-time
Jeff> option that could be turned off for strict JDK compatibility (or
Jeff> better performance/robustness in the case of Win32).

I think this would be a reasonable approach.

>> Secondly, I'm quite interested in doing some work on implementing
>> AWT (I'm more intrested in Client stuff myself). I was wondering if
>> someone could clear up the position of this, esp. regarding the
>> Classpath merger. I seem to recall that everything from Classpath
>> is available except the AWT code.  Now is this all AWT code or just
>> the native implementation? IF I do use it what is the final result?
>> That the executable is cover by the GPL? I can live with that for
>> now...

Jeff> From looking at Warren Levy's latest patches, I'd guess that the
Jeff> libgcj maintainers haven't given up on doing their own AWT port,
Jeff> independently of classpath.

Warren's recent patches notwithstanding, we haven't started
implementing AWT.  Those were needed for something else.

Jeff> AWT would be great... you might consider a portable toolkit
Jeff> (GTK?)  though before it becomes too Win32-centric, so that
Jeff> other platforms can benefit.

My goal is to have a retargetable AWT -- one where we can plug in
different back ends.  So we might have a Gtk+ back end (the one I'd
like to see :-), a Windows back end, and even a back end running on a
framebuffer (for embedded folks).  I don't know enough about AWT to
say whether this is a realistic plan.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:22       ` Tom Tromey
  2000-03-20 12:03         ` Paul Fisher
@ 2000-04-01  0:00         ` Tom Tromey
  1 sibling, 0 replies; 52+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon> Secondly, I'm quite interested in doing some work on implementing
Jon> AWT (I'm more intrested in Client stuff myself). I was wondering
Jon> if someone could clear up the position of this, esp. regarding
Jon> the Classpath merger. I seem to recall that everything from
Jon> Classpath is available except the AWT code.  Now is this all AWT
Jon> code or just the native implementation? IF I do use it what is
Jon> the final result? That the executable is cover by the GPL? I can
Jon> live with that for now...

All the AWT code in Classpath is under the GPL.  We aren't going to
merge it into libgcj.  It might be possible to get it to work with
libgcj; if you do so your resulting application will be GPL -- at
least, as I understand it.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 10:30           ` Per Bothner
  2000-03-20 12:42             ` Jeff Sturm
@ 2000-04-01  0:00             ` Per Bothner
  1 sibling, 0 replies; 52+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> My goal is to have a retargetable AWT -- one where we can plug in
> different back ends.  So we might have a Gtk+ back end (the one I'd
> like to see :-), a Windows back end, and even a back end running on a
> framebuffer (for embedded folks).  I don't know enough about AWT to
> say whether this is a realistic plan.

It is quite realistic - that is what the "peer" architecture
was meant to support.  However, Swing uses a different approach:
The actual widgets are written in "pure Java", using the operations
defined in java.awt.Graphics.

The two approaches have different trade-offs:
- Native peers can probably be implemented faster than a Swing-like
solution.
- Native peers may have better compatibility (both look-and-feel and
programming-wise) than pure Java widgets.
- Pure Java widgets as in Swing may make the system more coherent
and give better control.  It is probably is easier to get full
compatibility with Sun for the Swing widgets.
- Pure Java widgets allow compatibility with Swing's "pluggable-
look-and-feel" (PLAF).  However, I'm not sure that is important.
I would rather have PLAF built using (say) gtk's theability.

I suspect we may end up doing a little of both.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:03         ` Paul Fisher
@ 2000-04-01  0:00           ` Paul Fisher
  0 siblings, 0 replies; 52+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> All the AWT code in Classpath is under the GPL.

The GTK+ Peers are LGPL'd.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-22 17:30 Boehm, Hans
@ 2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 0 replies; 52+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: 'Tom Tromey', Bryce McKinlay, java-discuss

I haven't done much performance testing of GC_lock().  It does seem to be
appreciably faster than the pthread_mutex locking, apparently because there
is somewhat less work being done, there is one less level of procedure call,
it's less likely to enter the kernel on an SMP, and it doesn't need to do a
compare_and_swap on exit.

GC_lock isn't quite the strategy I had in mind, since it does something more
complicated than exponential back-off when it's spinning.  It tries to be
adaptive, but doesn't really back off between successive test_and_set
attempts while it's still spinning.  I have no idea how this compares to the
simpler straight exponential back-off strategy.

I agree that the current value of SLEEP_THRESHOLD is problematic on an SMP.
The problem with making it much larger is that sched_yield may be repatedly
yielding to another thread also waiting on the lock.  (This can definitely
happen with strict priorities.  Hopefully it's unlikely with normal
timesharing priorities.)  This may still be a better choice.  It would be
nice to be able to sleep for shorter intervals than 500 context switches.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:54 PM
To: Boehm, Hans
Cc: 'Tom Tromey'; Jeff Sturm; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: RE: Interrupted IO and AWT




On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal
in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21 14:21                   ` Paul Fisher
@ 2000-04-01  0:00                     ` Paul Fisher
  0 siblings, 0 replies; 52+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> One of the fundamental ideas of Swing is the separation of "model"
> and "view+controller".  For example two JTextPanes can both be using
> the same Document.  How suitable are gtk widgets for doing things
> like that?

It depends on the widget.  More of an issue, however, is Swing's
allowance of arbitrarily overriding of drawLine() and other
primitives, as was mentioned in a previous post.  With GTK+ 1.2, it's
impossible to do printing the way Java wants it done, because there's
no way to change the semantics of the primitive GDK drawing routines.
This issue is being resolved in GTK+ 1.4, so there might be a way
around the Swing issues such that Java methods can control the drawing
of GTK+ widgets.

All the issues involved will probably be quite complex, and I really
haven't had enough time to throughly think through them.  I'm more
focused on the libgcj/Classpath merger and finishing up the 1.1 AWT
before swamping myself in the problems of reimplementing Swing.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  7:07       ` Jeff Sturm
  2000-03-20  8:21         ` Tom Tromey
@ 2000-04-01  0:00         ` Jeff Sturm
  1 sibling, 0 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> I seem to recall reading somewhere on Sun's Bug list that the interrupting
> of IO has in some form been deprecated. Does any one know whether this is
> the case? I ask, because I'm wondering whether I should implement this in
> the Win32 port. It seems as if there may be some overhead. Would this be
> worth it it the general case? Personally, I've never made use of it.

This was covered in the thread last week on Thread.interrupt():
 
http://sourceware.cygnus.com/ml/java-discuss/2000-q1/msg00418.html

I think the collective opinion on this list was that both interruptable
I/O and resource revocation are desirable in libgcj.  If I had my
choice, interruptable I/O would be a configure-time option that could be
turned off for strict JDK compatibility (or better
performance/robustness in the case of Win32).

I remember reading somewhere that interruptible I/O can be implemented
on NT with async I/O, but that it won't work for 95/98 (which I couldn't
care less about, personally).  That may have changed since I read it...

> Secondly, I'm quite interested in doing some work on implementing AWT (I'm
> more intrested in Client stuff myself). I was wondering if someone could
> clear up the position of this, esp. regarding the Classpath merger. I seem
> to recall that everything from Classpath is available except the AWT code.
> Now is this all AWT code or just the native implementation? IF I do use it
> what is the final result? That the executable is cover by the GPL? I can
> live with that for now...

From looking at Warren Levy's latest patches, I'd guess that the libgcj
maintainers haven't given up on doing their own AWT port, independently
of classpath.

AWT would be great... you might consider a portable toolkit (GTK?)
though before it becomes too Win32-centric, so that other platforms can
benefit.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-22 17:10 Boehm, Hans
@ 2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 0 replies; 52+ messages in thread
From: Boehm, Hans @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: Tom Tromey, Bryce McKinlay, java-discuss

Ideally, I'd like to see measurements of collections of representative real
applications with various locking strategies :-).

Realistically, any measurements are much better than none.  My guess is that
even the following microbenchmark would yield some insight:

1) Acquire and release a single lock in a single thread in a tight loop.
2) Do (1) concurrently with different numbers of threads on different number
of processors, all acquiring the same lock. 

This is hopefully an unrealistically bad case, but it's probably more
representative of real applications than it should be.  

(Running a bunch of allocation tests concurrently essentially behaves like
this, if there is no per-thread allocation buffer.  I've certainly seen
interesting variation in the results.  I also thought someone posted test
results along these lines for some other locking schemes, but not spin locks
with exponential backoff.)

Hans

-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 12:20 PM
To: Boehm, Hans
Cc: Tom Tromey; Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


"Boehm, Hans" wrote:
[Exponential back-off spin locks:]
> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include
something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  8:06                     ` Jeff Sturm
@ 2000-04-01  0:00                       ` Jeff Sturm
  0 siblings, 0 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Bryce McKinlay, java-discuss

Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-22 17:30 Boehm, Hans
  2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 1 reply; 52+ messages in thread
From: Boehm, Hans @ 2000-03-22 17:30 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: 'Tom Tromey', Bryce McKinlay, java-discuss

I haven't done much performance testing of GC_lock().  It does seem to be
appreciably faster than the pthread_mutex locking, apparently because there
is somewhat less work being done, there is one less level of procedure call,
it's less likely to enter the kernel on an SMP, and it doesn't need to do a
compare_and_swap on exit.

GC_lock isn't quite the strategy I had in mind, since it does something more
complicated than exponential back-off when it's spinning.  It tries to be
adaptive, but doesn't really back off between successive test_and_set
attempts while it's still spinning.  I have no idea how this compares to the
simpler straight exponential back-off strategy.

I agree that the current value of SLEEP_THRESHOLD is problematic on an SMP.
The problem with making it much larger is that sched_yield may be repatedly
yielding to another thread also waiting on the lock.  (This can definitely
happen with strict priorities.  Hopefully it's unlikely with normal
timesharing priorities.)  This may still be a better choice.  It would be
nice to be able to sleep for shorter intervals than 500 context switches.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:54 PM
To: Boehm, Hans
Cc: 'Tom Tromey'; Jeff Sturm; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: RE: Interrupted IO and AWT




On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal
in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-22 17:10 Boehm, Hans
  2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 1 reply; 52+ messages in thread
From: Boehm, Hans @ 2000-03-22 17:10 UTC (permalink / raw)
  To: 'Jeff Sturm', Boehm, Hans
  Cc: Tom Tromey, Bryce McKinlay, java-discuss

Ideally, I'd like to see measurements of collections of representative real
applications with various locking strategies :-).

Realistically, any measurements are much better than none.  My guess is that
even the following microbenchmark would yield some insight:

1) Acquire and release a single lock in a single thread in a tight loop.
2) Do (1) concurrently with different numbers of threads on different number
of processors, all acquiring the same lock. 

This is hopefully an unrealistically bad case, but it's probably more
representative of real applications than it should be.  

(Running a bunch of allocation tests concurrently essentially behaves like
this, if there is no per-thread allocation buffer.  I've certainly seen
interesting variation in the results.  I also thought someone posted test
results along these lines for some other locking schemes, but not spin locks
with exponential backoff.)

Hans

-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 12:20 PM
To: Boehm, Hans
Cc: Tom Tromey; Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


"Boehm, Hans" wrote:
[Exponential back-off spin locks:]
> For some strange reason, that's a scheme that's rarely discussed in the
> literature.  Does anyone have some real measurements that include
something
> like this scheme?

No.  What would you suggest measuring?  I'm interested in it but
somewhat lacking in experience.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
  2000-03-21 16:05 Boehm, Hans
@ 2000-03-21 20:49 ` Jeff Sturm
  2000-04-01  0:00   ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  1 sibling, 1 reply; 52+ messages in thread
From: Jeff Sturm @ 2000-03-21 20:49 UTC (permalink / raw)
  To: Boehm, Hans
  Cc: 'Tom Tromey', Jeff Sturm, Bryce McKinlay, java-discuss

On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case.  There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2).  Clearly this is suboptimal in
> this case.  But are there cases in which it's a serious problem?

I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
linux_threads.c)?

There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms.  On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place.  It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed.  The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.

I'd question if suspend/resume could be any more effective over such a
duration (~1ms).  I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.


--
Jeff Sturm
jsturm@sigma6.com


^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Interrupted IO and AWT
@ 2000-03-21 16:05 Boehm, Hans
  2000-03-21 20:49 ` Jeff Sturm
  2000-04-01  0:00 ` Boehm, Hans
  0 siblings, 2 replies; 52+ messages in thread
From: Boehm, Hans @ 2000-03-21 16:05 UTC (permalink / raw)
  To: 'Tom Tromey', Jeff Sturm; +Cc: Bryce McKinlay, java-discuss

It seems to me that a spin lock with exponential back-off (and sleeps for
longer wait times) doesn't behave that badly, even in this case.  There'll
be some unneeded wakeups on the part of the waiting thread near the
beginning, and it may sleep for up to about twice as long as it should
(assuming the base of the exponential is 2).  Clearly this is suboptimal in
this case.  But are there cases in which it's a serious problem?

Hans 

-----Original Message-----
From: Tom Tromey [ mailto:tromey@cygnus.com ]
Sent: Tuesday, March 21, 2000 1:30 PM
To: Jeff Sturm
Cc: Boehm, Hans; Tom Tromey; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:

Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.

One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin.  There are a lot of tradeoffs to make if we take
this route.

It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances.  For "big" implementations we should definitely
consider an adaptive approach.  If I ever have time I'll dig up the
literature on this stuff.  Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:25                 ` Per Bothner
@ 2000-03-21 14:21                   ` Paul Fisher
  2000-04-01  0:00                     ` Paul Fisher
  2000-04-01  0:00                   ` Per Bothner
  1 sibling, 1 reply; 52+ messages in thread
From: Paul Fisher @ 2000-03-21 14:21 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> One of the fundamental ideas of Swing is the separation of "model"
> and "view+controller".  For example two JTextPanes can both be using
> the same Document.  How suitable are gtk widgets for doing things
> like that?

It depends on the widget.  More of an issue, however, is Swing's
allowance of arbitrarily overriding of drawLine() and other
primitives, as was mentioned in a previous post.  With GTK+ 1.2, it's
impossible to do printing the way Java wants it done, because there's
no way to change the semantics of the primitive GDK drawing routines.
This issue is being resolved in GTK+ 1.4, so there might be a way
around the Swing issues such that Java methods can control the drawing
of GTK+ widgets.

All the issues involved will probably be quite complex, and I really
haven't had enough time to throughly think through them.  I'm more
focused on the libgcj/Classpath merger and finishing up the 1.1 AWT
before swamping myself in the problems of reimplementing Swing.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-21  7:18                   ` Tom Tromey
@ 2000-03-21  8:06                     ` Jeff Sturm
  2000-04-01  0:00                       ` Jeff Sturm
  2000-04-01  0:00                     ` Tom Tromey
  1 sibling, 1 reply; 52+ messages in thread
From: Jeff Sturm @ 2000-03-21  8:06 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Bryce McKinlay, java-discuss

Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 17:48                 ` Bryce McKinlay
@ 2000-03-21  7:18                   ` Tom Tromey
  2000-03-21  8:06                     ` Jeff Sturm
  2000-04-01  0:00                     ` Tom Tromey
  2000-04-01  0:00                   ` Bryce McKinlay
  1 sibling, 2 replies; 52+ messages in thread
From: Tom Tromey @ 2000-03-21  7:18 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: Per Bothner, java-discuss

Bryce> The queue lock is always under contention by the thread(s)
Bryce> putting events onto it and the E.D.T. pulling events off it,
Bryce> and as we know, locking between native threads is slow. I
Bryce> suspect this is the major reason why the user-threads based
Bryce> Sun/Borland JDK 1.2.2 performs so well running JBuilder and
Bryce> other swing apps compared to the other, native threaded JDKs
Bryce> like IBM 1.1.8 (which by all benchmarks has a much superior JIT
Bryce> and memory management) - its thread synchronization is 5x or
Bryce> more faster than linux native locks.

Sometimes I wonder if we should have two locking implementations, one
as fast as possible and one that is perhaps slower but SMP friendly.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:17               ` Per Bothner
@ 2000-03-20 17:48                 ` Bryce McKinlay
  2000-03-21  7:18                   ` Tom Tromey
  2000-04-01  0:00                   ` Bryce McKinlay
  2000-04-01  0:00                 ` Per Bothner
  1 sibling, 2 replies; 52+ messages in thread
From: Bryce McKinlay @ 2000-03-20 17:48 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

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.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 13:09               ` Paul Fisher
@ 2000-03-20 13:25                 ` Per Bothner
  2000-03-21 14:21                   ` Paul Fisher
  2000-04-01  0:00                   ` Per Bothner
  2000-04-01  0:00                 ` Paul Fisher
  1 sibling, 2 replies; 52+ messages in thread
From: Per Bothner @ 2000-03-20 13:25 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> I don't believe it would be feasible to actually implement Swing using
> GTK+ or Qt (for example, directly mapping the Swing tree widget to
> GTK+'s tree widget).  However, I've often thought about this
> possibility; it's certainly appealing.

One of the fundamental ideas of Swing is the separation of "model"
and "view+controller".  For example two JTextPanes can both be using the
same Document.  How suitable are gtk widgets for doing things like that?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42             ` Jeff Sturm
  2000-03-20 12:51               ` Tom Tromey
  2000-03-20 13:09               ` Paul Fisher
@ 2000-03-20 13:17               ` Per Bothner
  2000-03-20 17:48                 ` Bryce McKinlay
  2000-04-01  0:00                 ` Per Bothner
  2000-04-01  0:00               ` Jeff Sturm
  3 siblings, 2 replies; 52+ messages in thread
From: Per Bothner @ 2000-03-20 13:17 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> To my knowledge there exist no free or third-party implementations of
> Swing.  It could be extremely difficult to do.

I know.  My recommendation is to write a subset of Swing (and AWT), and
enhancing it as people feel motivated.

> I'd like to see real Java bindings in GTK and/or KDE so developers can
> write first class Java apps for those environments.  Then implement AWT
> and (possibly) Swing atop this native API to be compatibile with other
> Java applications.

I agree with one slight modification:  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.  The main thing is I want to
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.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42             ` Jeff Sturm
  2000-03-20 12:51               ` Tom Tromey
@ 2000-03-20 13:09               ` Paul Fisher
  2000-03-20 13:25                 ` Per Bothner
  2000-04-01  0:00                 ` Paul Fisher
  2000-03-20 13:17               ` Per Bothner
  2000-04-01  0:00               ` Jeff Sturm
  3 siblings, 2 replies; 52+ messages in thread
From: Paul Fisher @ 2000-03-20 13:09 UTC (permalink / raw)
  To: java-discuss

Jeff Sturm <jsturm@sigma6.com> writes:

> Let's say somebody wants to use gcj to write desktop apps for KDE or
> Gnome.  How would they best proceed?

Currently, using the standard Java AWT API is their best bet, with the
GTK+ Peer libraries from Classpath.  There's also the `java-gnome'
project <URL: http://www.lirmm.fr/~gutkneco/devpt/javagnome.html >,
which provides Java bindings for the GTK+ and Gnome APIs.

I read somewhere recently that the KDE project has started work on a
set of Qt AWT peers, but I don't have a URL handy.

> The PLAF's are a bad idea because they don't leverage a native
> toolkit, they attempt to reimplement it in Java.

There's no reason why a Swing PLAF couldn't be written that does
leverage the native toolkit.  (A GTK+ Swing PLAF is on the TODO list
for Classpath).

> AWT isn't so good either because it doesn't leverage much of the
> capability of good toolkits out there... e.g. there is no tree
> widget or image button in AWT.

Strictly speaking, it's permissible for getGraphics to return a valid
Graphics object for any Component.  The peer side, however, is only
required to return a valid Graphics object for Canvas and Container.
So, it is possible (and legal) to doodle on random widgets, assuming
the peer implementation supports it.

> Then implement AWT and (possibly) Swing atop this native API to be
> compatibile with other Java applications.

Swing, by design, only depends on the basic drawing primitives of the
AWT.

I don't believe it would be feasible to actually implement Swing using
GTK+ or Qt (for example, directly mapping the Swing tree widget to
GTK+'s tree widget).  However, I've often thought about this
possibility; it's certainly appealing.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 12:42             ` Jeff Sturm
@ 2000-03-20 12:51               ` Tom Tromey
  2000-04-01  0:00                 ` Tom Tromey
  2000-03-20 13:09               ` Paul Fisher
                                 ` (2 subsequent siblings)
  3 siblings, 1 reply; 52+ messages in thread
From: Tom Tromey @ 2000-03-20 12:51 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Per Bothner, java-discuss

Jeff> I'd like to see real Java bindings in GTK and/or KDE so developers can
Jeff> write first class Java apps for those environments.  Then implement AWT
Jeff> and (possibly) Swing atop this native API to be compatibile with other
Jeff> Java applications.

I believe there is a Java/Gnome effort, which provides Java bindings
for Gtk and Gnome.  I haven't looked to see how hard it would be to
make it work with gcj.

I think this is a reasonable approach as well.  We still need AWT and
Swing for compatibility and for people who want to write "Java
portable" applicatoins.

This also opens up the possibly weird capability of writing a pure
Java AWT on top of the Java Gtk package.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20 10:30           ` Per Bothner
@ 2000-03-20 12:42             ` Jeff Sturm
  2000-03-20 12:51               ` Tom Tromey
                                 ` (3 more replies)
  2000-04-01  0:00             ` Per Bothner
  1 sibling, 4 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-03-20 12:42 UTC (permalink / raw)
  To: Per Bothner; +Cc: java-discuss

Per Bothner wrote:
> The two approaches have different trade-offs:
> - Native peers can probably be implemented faster than a Swing-like
> solution.

To my knowledge there exist no free or third-party implementations of
Swing.  It could be extremely difficult to do.

> - Native peers may have better compatibility (both look-and-feel and
> programming-wise) than pure Java widgets.

Especially if a toolkit (i.e. GTK+) is used.  It's also possible to
write native peers using Xlib or Win32/GDI directly... though this leads
to the same interoperability problems as Swing.

(Sun never really got this part right.  AWT applications on Linux don't
look right because Sun used the archaic Motif toolkit.  Early versions
of the Win32 JDK did use MFC to inherit a certain amount of Win32
behavior, but that was later scrapped for direct window/graphics calls.)

> - Pure Java widgets allow compatibility with Swing's "pluggable-
> look-and-feel" (PLAF).  However, I'm not sure that is important.
> I would rather have PLAF built using (say) gtk's theability.

Me too.

Let's say somebody wants to use gcj to write desktop apps for KDE or
Gnome.  How would they best proceed?  Swing is not a good fit because
apps written in Swing tend to look like, umm, Swing.  The PLAF's are a
bad idea because they don't leverage a native toolkit, they attempt to
reimplement it in Java.  Consequently Swing PLAFs are both difficult to
write and imperfect in their emulation.

AWT isn't so good either because it doesn't leverage much of the
capability of good toolkits out there... e.g. there is no tree widget or
image button in AWT.

I'd like to see real Java bindings in GTK and/or KDE so developers can
write first class Java apps for those environments.  Then implement AWT
and (possibly) Swing atop this native API to be compatibile with other
Java applications.

To me this is consistent with the apparent philosophy of the gcj
project: remain compatible with Java but innovate where appropriate. 
Gcj has already innovated with CNI.

(Those who are in the "pure Java" camp will likely disagree with me.  My
aim is not to compromise Java compatibility, but extend its reach to
application domains where it has flopped, like desktop programming.)


-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:22       ` Tom Tromey
@ 2000-03-20 12:03         ` Paul Fisher
  2000-04-01  0:00           ` Paul Fisher
  2000-04-01  0:00         ` Tom Tromey
  1 sibling, 1 reply; 52+ messages in thread
From: Paul Fisher @ 2000-03-20 12:03 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> All the AWT code in Classpath is under the GPL.

The GTK+ Peers are LGPL'd.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  8:21         ` Tom Tromey
@ 2000-03-20 10:30           ` Per Bothner
  2000-03-20 12:42             ` Jeff Sturm
  2000-04-01  0:00             ` Per Bothner
  2000-04-01  0:00           ` Tom Tromey
  1 sibling, 2 replies; 52+ messages in thread
From: Per Bothner @ 2000-03-20 10:30 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> My goal is to have a retargetable AWT -- one where we can plug in
> different back ends.  So we might have a Gtk+ back end (the one I'd
> like to see :-), a Windows back end, and even a back end running on a
> framebuffer (for embedded folks).  I don't know enough about AWT to
> say whether this is a realistic plan.

It is quite realistic - that is what the "peer" architecture
was meant to support.  However, Swing uses a different approach:
The actual widgets are written in "pure Java", using the operations
defined in java.awt.Graphics.

The two approaches have different trade-offs:
- Native peers can probably be implemented faster than a Swing-like
solution.
- Native peers may have better compatibility (both look-and-feel and
programming-wise) than pure Java widgets.
- Pure Java widgets as in Swing may make the system more coherent
and give better control.  It is probably is easier to get full
compatibility with Sun for the Swing widgets.
- Pure Java widgets allow compatibility with Swing's "pluggable-
look-and-feel" (PLAF).  However, I'm not sure that is important.
I would rather have PLAF built using (say) gtk's theability.

I suspect we may end up doing a little of both.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  6:19     ` Interrupted IO and AWT Jon Beniston
  2000-03-20  7:07       ` Jeff Sturm
@ 2000-03-20  8:22       ` Tom Tromey
  2000-03-20 12:03         ` Paul Fisher
  2000-04-01  0:00         ` Tom Tromey
  2000-04-01  0:00       ` Jon Beniston
  2 siblings, 2 replies; 52+ messages in thread
From: Tom Tromey @ 2000-03-20  8:22 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon> Secondly, I'm quite interested in doing some work on implementing
Jon> AWT (I'm more intrested in Client stuff myself). I was wondering
Jon> if someone could clear up the position of this, esp. regarding
Jon> the Classpath merger. I seem to recall that everything from
Jon> Classpath is available except the AWT code.  Now is this all AWT
Jon> code or just the native implementation? IF I do use it what is
Jon> the final result? That the executable is cover by the GPL? I can
Jon> live with that for now...

All the AWT code in Classpath is under the GPL.  We aren't going to
merge it into libgcj.  It might be possible to get it to work with
libgcj; if you do so your resulting application will be GPL -- at
least, as I understand it.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  7:07       ` Jeff Sturm
@ 2000-03-20  8:21         ` Tom Tromey
  2000-03-20 10:30           ` Per Bothner
  2000-04-01  0:00           ` Tom Tromey
  2000-04-01  0:00         ` Jeff Sturm
  1 sibling, 2 replies; 52+ messages in thread
From: Tom Tromey @ 2000-03-20  8:21 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: Jon Beniston, java-discuss

Jeff> If I had my choice, interruptable I/O would be a configure-time
Jeff> option that could be turned off for strict JDK compatibility (or
Jeff> better performance/robustness in the case of Win32).

I think this would be a reasonable approach.

>> Secondly, I'm quite interested in doing some work on implementing
>> AWT (I'm more intrested in Client stuff myself). I was wondering if
>> someone could clear up the position of this, esp. regarding the
>> Classpath merger. I seem to recall that everything from Classpath
>> is available except the AWT code.  Now is this all AWT code or just
>> the native implementation? IF I do use it what is the final result?
>> That the executable is cover by the GPL? I can live with that for
>> now...

Jeff> From looking at Warren Levy's latest patches, I'd guess that the
Jeff> libgcj maintainers haven't given up on doing their own AWT port,
Jeff> independently of classpath.

Warren's recent patches notwithstanding, we haven't started
implementing AWT.  Those were needed for something else.

Jeff> AWT would be great... you might consider a portable toolkit
Jeff> (GTK?)  though before it becomes too Win32-centric, so that
Jeff> other platforms can benefit.

My goal is to have a retargetable AWT -- one where we can plug in
different back ends.  So we might have a Gtk+ back end (the one I'd
like to see :-), a Windows back end, and even a back end running on a
framebuffer (for embedded folks).  I don't know enough about AWT to
say whether this is a realistic plan.

Tom

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Interrupted IO and AWT
  2000-03-20  6:19     ` Interrupted IO and AWT Jon Beniston
@ 2000-03-20  7:07       ` Jeff Sturm
  2000-03-20  8:21         ` Tom Tromey
  2000-04-01  0:00         ` Jeff Sturm
  2000-03-20  8:22       ` Tom Tromey
  2000-04-01  0:00       ` Jon Beniston
  2 siblings, 2 replies; 52+ messages in thread
From: Jeff Sturm @ 2000-03-20  7:07 UTC (permalink / raw)
  To: Jon Beniston; +Cc: java-discuss

Jon Beniston wrote:
> I seem to recall reading somewhere on Sun's Bug list that the interrupting
> of IO has in some form been deprecated. Does any one know whether this is
> the case? I ask, because I'm wondering whether I should implement this in
> the Win32 port. It seems as if there may be some overhead. Would this be
> worth it it the general case? Personally, I've never made use of it.

This was covered in the thread last week on Thread.interrupt():
 
http://sourceware.cygnus.com/ml/java-discuss/2000-q1/msg00418.html

I think the collective opinion on this list was that both interruptable
I/O and resource revocation are desirable in libgcj.  If I had my
choice, interruptable I/O would be a configure-time option that could be
turned off for strict JDK compatibility (or better
performance/robustness in the case of Win32).

I remember reading somewhere that interruptible I/O can be implemented
on NT with async I/O, but that it won't work for 95/98 (which I couldn't
care less about, personally).  That may have changed since I read it...

> Secondly, I'm quite interested in doing some work on implementing AWT (I'm
> more intrested in Client stuff myself). I was wondering if someone could
> clear up the position of this, esp. regarding the Classpath merger. I seem
> to recall that everything from Classpath is available except the AWT code.
> Now is this all AWT code or just the native implementation? IF I do use it
> what is the final result? That the executable is cover by the GPL? I can
> live with that for now...

From looking at Warren Levy's latest patches, I'd guess that the libgcj
maintainers haven't given up on doing their own AWT port, independently
of classpath.

AWT would be great... you might consider a portable toolkit (GTK?)
though before it becomes too Win32-centric, so that other platforms can
benefit.

-- 
Jeff Sturm
jsturm@sigma6.com

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Interrupted IO and AWT
  2000-04-01  0:00   ` Jeff Sturm
@ 2000-03-20  6:19     ` Jon Beniston
  2000-03-20  7:07       ` Jeff Sturm
                         ` (2 more replies)
  0 siblings, 3 replies; 52+ messages in thread
From: Jon Beniston @ 2000-03-20  6:19 UTC (permalink / raw)
  To: java-discuss

Hi,

I seem to recall reading somewhere on Sun's Bug list that the interrupting
of IO has in some form been deprecated. Does any one know whether this is
the case? I ask, because I'm wondering whether I should implement this in
the Win32 port. It seems as if there may be some overhead. Would this be
worth it it the general case? Personally, I've never made use of it.

Secondly, I'm quite interested in doing some work on implementing AWT (I'm
more intrested in Client stuff myself). I was wondering if someone could
clear up the position of this, esp. regarding the Classpath merger. I seem
to recall that everything from Classpath is available except the AWT code.
Now is this all AWT code or just the native implementation? IF I do use it
what is the final result? That the executable is cover by the GPL? I can
live with that for now...

Jon Beniston.

^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-21  9:20 Interrupted IO and AWT Boehm, Hans
2000-03-21  9:52 ` Tom Tromey
2000-03-21 12:31   ` Jeff Sturm
2000-03-21 12:39     ` Per Bothner
2000-04-01  0:00       ` Per Bothner
2000-03-21 13:23     ` Tom Tromey
2000-04-01  0:00       ` Tom Tromey
2000-04-01  0:00     ` Jeff Sturm
2000-04-01  0:00   ` Tom Tromey
2000-03-21 12:17 ` Jeff Sturm
2000-03-21 13:30   ` Tom Tromey
2000-04-01  0:00     ` Tom Tromey
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00 ` Boehm, Hans
2000-03-21 16:05 Boehm, Hans
2000-03-21 20:49 ` Jeff Sturm
2000-04-01  0:00   ` Jeff Sturm
2000-04-01  0:00 ` Boehm, Hans
2000-03-22 17:10 Boehm, Hans
2000-04-01  0:00 ` Boehm, Hans
2000-03-22 17:30 Boehm, Hans
2000-04-01  0:00 ` Boehm, Hans
2000-04-01  0:00 libgcj for win32 Jeff Sturm
2000-04-01  0:00 ` Jon Beniston
2000-04-01  0:00   ` Jeff Sturm
2000-03-20  6:19     ` Interrupted IO and AWT Jon Beniston
2000-03-20  7:07       ` Jeff Sturm
2000-03-20  8:21         ` Tom Tromey
2000-03-20 10:30           ` Per Bothner
2000-03-20 12:42             ` Jeff Sturm
2000-03-20 12:51               ` Tom Tromey
2000-04-01  0:00                 ` Tom Tromey
2000-03-20 13:09               ` Paul Fisher
2000-03-20 13:25                 ` Per Bothner
2000-03-21 14:21                   ` Paul Fisher
2000-04-01  0:00                     ` Paul Fisher
2000-04-01  0:00                   ` Per Bothner
2000-04-01  0:00                 ` Paul Fisher
2000-03-20 13:17               ` Per Bothner
2000-03-20 17:48                 ` Bryce McKinlay
2000-03-21  7:18                   ` Tom Tromey
2000-03-21  8:06                     ` Jeff Sturm
2000-04-01  0:00                       ` Jeff Sturm
2000-04-01  0:00                     ` Tom Tromey
2000-04-01  0:00                   ` Bryce McKinlay
2000-04-01  0:00                 ` Per Bothner
2000-04-01  0:00               ` Jeff Sturm
2000-04-01  0:00             ` Per Bothner
2000-04-01  0:00           ` Tom Tromey
2000-04-01  0:00         ` Jeff Sturm
2000-03-20  8:22       ` Tom Tromey
2000-03-20 12:03         ` Paul Fisher
2000-04-01  0:00           ` Paul Fisher
2000-04-01  0:00         ` Tom Tromey
2000-04-01  0:00       ` Jon Beniston

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).