On Fri, 7 Apr 2023 20:38:47 GMT, Phil Race <p...@openjdk.org> wrote:

> Multiple seconds seems out of bounds (so to speak :-)), for network latency 
> of an X11 round trip.

Most certainly. What I actually measured was the time (min, max, and average) 
the AWT lock was being held by a method.

In fact, the story began with 
[fakexrandr](https://github.com/phillipberndt/fakexrandr), a tool that divides 
one monitor into several for purposes beyond my comprehension (testing, 
perhaps?) When this tool is configured to fake many monitors (don't remember 
the exact number, but it was around 10 or more), it starts to introduce 
significant delays that [annoyed some 
users](https://github.com/phillipberndt/fakexrandr/issues/64#issuecomment-901877835).

Normally, `X11GraphicsDevice.pGetBounds()` holds the AWT lock for 1 ms on 
average with 11 ms max in one of the experiments.. `fakexrandr` managed to 
bring this number up to 34ms on average, which - together with 
`XToolkit.getScreenInsets()` - was the only difference between "fast" and 
"sluggish" GUI that users were reporting. Other operations took about the same 
amount of time.

But it wasn't just about `fakexrandr`: I also noticed that a remote X session 
has the same effect as `fakexrandr`. As an example, on a remote machine the 
call to `XToolkit.getScreenInsets()` holds the AWT lock for 69ms on average 
with a whopping 830ms peak. As is obvious from the average number, such a long 
delay doesn't happen frequently, so it's very hard to start profiling at 
exactly the right moment in order to try to find out the underlying cause.

In the end, I'm sure it's about the timing of *other* operations that take the 
AWT lock coupled with the delays introduced by `XineramaQueryScreens()` and 
friends. Perhaps the recent 
[commit](https://github.com/openjdk/jdk/commit/dc81603cbf223c3ac6b41396d1998a07524a0d54)
 for `8305666: Add system property for fair AWT lock` may also help with this, 
but it wouldn't be as effective as this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1501473318

Reply via email to