-
Bug
-
Resolution: Fixed
-
P4
-
17
We've seen several services running JDK17 with excessive CPU wasted on AbstractQueuedSynchronizer.isEnqueued. Calls to this method may represent up to 25% of CPU usage in some services, with more hovering around the 10% mark. We did not see this with JDK11 (AQS relevant methods were added in JDK14 as part of JDK-8229442) or JDK21
Top of the stack for that block consists of:
java/util/concurrent/locks/AbstractQueuedSynchronizer.isEnqueued (24.60%)
java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.canReacquire (24.60%)
java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.await (26.39%)
java/util/concurrent/ScheduledThreadPoolExecutor$DelayedWorkQueue.take (27.75%)
Testing the same applications with JDK21 causes all that CPU usage to go away, with AbstractQueuedSynchronizer$ConditionObject.await taking just (0.11% of cpu).
It seems the performance fix comes fromJDK-8277090. Backporting the AQS related changes to JDK17 seems to fix the performance issue, although it is not clear based on JDK-8277090 if those changes are dependent on other
Top of the stack for that block consists of:
java/util/concurrent/locks/AbstractQueuedSynchronizer.isEnqueued (24.60%)
java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.canReacquire (24.60%)
java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.await (26.39%)
java/util/concurrent/ScheduledThreadPoolExecutor$DelayedWorkQueue.take (27.75%)
Testing the same applications with JDK21 causes all that CPU usage to go away, with AbstractQueuedSynchronizer$ConditionObject.await taking just (0.11% of cpu).
It seems the performance fix comes from
- relates to
-
JDK-8277090 jsr166 refresh for jdk19
- Resolved
-
JDK-8229442 AQS and lock classes refresh
- Resolved