Strange interaction with hyperthreading on Intel hybrid CPU

Michael van Acken michael.van.acken at gmail.com
Wed Oct 11 16:54:30 UTC 2023


Given the huge difference of a factor of 2 in user time between the default
and the nosmt setup, I tried to use jfr to find some metric that differs
markedly between the two.  The workload is the same: the very same task is
executed leading to the expected result.  This time it's 300 back to back
compilations within a single java process.  Using the threadId() of a final
virtual thread as proxy, ~570k threads seem to be utilized overall.

"jfr view hot-methods" does not show any significant difference, with the
top entry being ForkJoinPool.awaitWork() at around 5.5% in both cases.

But "jfr view latencies-by-type" shows a large difference in its Total
column for "Java Thread Park".  Could this be a clue where the user time
accumulates?

### with "nosmt"

real 77.67
user 468.16
sys 13.48

jfr view latencies-by-type recording.jfr
                               Latencies by Type

Event Type                              Count Average    P 99 Longest
Total
-------------------------------------- ------ ------- ------- -------
---------
Java Thread Park                       18.651 36,9 ms  310 ms  2,88 s 11 m
43 s
File Write                                  2 11,7 ms 12,6 ms 12,6 ms
23,4 ms

### default (without "nosmt")

real 93.60
user 824.12
sys 23.08

jfr view latencies-by-type recording.jfr
                               Latencies by Type

Event Type                               Count Average    P 99 Longest
 Total
--------------------------------------- ------ ------- ------- -------
--------
Java Thread Park                        30.263 45,7 ms  256 ms  504 ms 23 m
2 s
File Read                                    1 10,9 ms 10,9 ms 10,9 ms
 10,9 ms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231011/299ec7cc/attachment-0001.htm>


More information about the loom-dev mailing list