Use monotonic clock for relative timed waits - #17
Merged
Conversation
guillerodriguez
changed the title
phvega
previously approved these changes
Jul 24, 2026
guillerodriguez
force-pushed
the
feat/use-monotonic-clock-v4
branch
from
July 31, 2026 09:10
31adf01 to
d2166e6
Compare
phvega
approved these changes
Jul 31, 2026
Contributor
Author
|
CI is failing for the OpenJDK builds. It seems to be an unrelated issue (a blocked signals test). Will have a look. |
Contributor
Author
|
See #18. |
Contributor
Author
|
Must rebase on top of master to get the fix from #19. |
The timedWaitVMWaitLock macro duplicates the deadline calculation already implemented by getTimeoutRelative(). Make the macro defer to the function instead, so relative timeout deadlines are computed in a single place. Signed-off-by: Guillermo Rodríguez <grodriguez@ingelabs.com>
The OpenJDK class library code probes CLOCK_MONOTONIC availability at runtime for use by JVM_NanoTime. Move the probe to common code (time.c), run it early in the VM initialisation sequence, and expose it as haveMonotonicClock(). Signed-off-by: Guillermo Rodríguez <grodriguez@ingelabs.com>
Introduce initReltimeCondVar() for initialising condition variables used with relative timeouts, and use it for all such condvars (the per-thread wait and park condvars, and VM-internal wait locks). A timed park (threadPark) can take either a relative timeout or an absolute wall-clock deadline, but currently both waits share the per-thread park condvar, and a condvar can only be bound to one clock. Split it in two: park_cv (relative and untimed parks) and park_cv_abs (absolute deadlines), choosing the right one when parking. Unparking signals both; signalling a condvar nobody waits on is harmless and cheap. All condvars are still bound to the default realtime clock, so no change in behaviour; this puts the infrastructure in place for switching relative timeouts to the monotonic clock. Signed-off-by: Guillermo Rodríguez <grodriguez@ingelabs.com>
All relative timeouts were computed against the wall clock, so stepping the system time backward stretched them and stepping it forward truncated them. Fix this by binding the condvars used for relative timed waits to CLOCK_MONOTONIC, if available, and make getTimeoutRelative() use the same clock when computing the deadline. If the monotonic clock cannot be used, behaviour is unchanged and a warning is printed at startup. Signed-off-by: Guillermo Rodríguez <grodriguez@ingelabs.com>
guillerodriguez
force-pushed
the
feat/use-monotonic-clock-v4
branch
from
August 12, 2026 12:25
d2166e6 to
a6d0f6a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.