-
Notifications
You must be signed in to change notification settings - Fork 989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shenandoah pause time includes concurrent phases #2377
Comments
Hi there, Hi I am not sure yet, but I noticed that in the following graph the
And at the same time these are the real concurrent actions.
When the manager name is not
Shenandoah documentation don't dive in this GC notification topic. Another case, focusing on the
Looking at the GC logs around 17:05 (from 750s to 910s), there's no pauses that goes up to 170 ms, yet they are indeed a few pauses (~10 to ~26ms) related to That leads me to doubt the correctness of the real pause value for Shenandoah. Not sure Micrometer can do something about it though. |
I found the following in the logs, so it seems the metrics align with the gc logs.
I agree it is unexpected from the naming, and we could reach out to the Shenandoah team at their mailing list to seek clarification, but my understanding is that despite the cause being |
Similar to #2372, after a closer look at our gc pause metrics reported, they do not match up with the gc logging. Among the
GarbageCollectorMXBean
andGarbageCollectionNotificationInfo
, it seems theShenandoah Cycles
gc name corresponds to the concurrent phase time and should not be counted in the pauses. I could not find this documented on the Shenandoah wiki. However, judging from the spectator implementation and since the gc logging is more clear about what time is spent where, I think we can update our implementation to countShenandoah Cycles
as concurrent phase time.The text was updated successfully, but these errors were encountered: