3

I understand that the sleeping time isn't precise or as precise as the OS could make it be.

Assuming no other extreme factors..

My question is what if a thread starts sleeping for say, 10 seconds, then a GC hits after 5 seconds (in the middle of the thread sleeping time) and continues for 10 seconds, will the thread end sleeping right away or will it sleep for more 5 seconds (overall 20 seconds) ?

Muhammad Gelbana
  • 3,890
  • 3
  • 43
  • 81

2 Answers2

3

This depends on a few factors, but in general the answer has to be 15, give or take (more give vs take). It depends on where the safe-point poll is when executing sleep. In my mind a thread is already at a safepoint when it executes sleep (and I see no reason to do it otherwise + it seems maaartinus has the same thought). You can read here why that would matter.

So your thread has slept for 5 seconds, GC kicks in and does a stop-the-world (AFAIK the GC thread "protects" the page and as such a "memory protection error" happens and this is how the VM does a safepoint poll), so the entire application stops for 10 seconds, but wall clock time has still progressed. As such there is no point in sleeping 5 more seconds; it is easily determined that the thread has already slept enough.

Eugene
  • 117,005
  • 15
  • 201
  • 306
2

My question is what if a thread starts sleeping for say, 10 seconds, then a GC hits after 5 seconds (in the middle of the thread sleeping time) and continues for 10 seconds, will the thread end sleeping right away or will it sleep for more 5 seconds (overall 20 seconds) ?

I suppose you're asking about a stop-the-world GC, which is not the only or most common kind. All non-GC threads are ineligible to run during such a GC, but sleep() time does not (directly) take that into account.

You can think of sleep() as making the invoking thread ineligible to run until a specific future time. It will typically resume very soon after that time arrives, but if something else, such as a then-running GC, prevents it from doing so then its resumption will be delayed until after that situation is resolved. To put it another way, GC time can overlap sleep time, but the two are separate and independent factors that each (temporarily) prevents a thread from progressing.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • a `STW` event has to bring the thread that does the sleep to a safepoint, so it all depends where that safepoint poll is in case of `sleep` (I do not know this); but in general the answer should be _20_ seconds, give or take. Is that what you are answering here? Sorry, I tried to read it a few times, but no clear understanding. – Eugene Feb 04 '20 at 14:27
  • The `until a specific future time` makes it sound like the waking-up time is calculated, as in adding the sleeping time to the current time, and waking up on that time. But then you said that the two factors (sleeping and STW) are separate and independent, which means that they'll both add to the overall thread sleeping/delay. I'm inclined to picture it this way, as a counting down hourglass, which simply freezes if on a STW, then resumes counting down after the event. – Muhammad Gelbana Feb 04 '20 at 14:55
  • 2
    @Eugene A sleeping thread must count as being already at a safepoint; otherwise, the JVM waiting for all threads reaching a safepoint could be delayed indefinitely. IMHO the answer must be 15 seconds with the first 5 coming from the sleep and the remaining 10 coming from the GC. There's no reason to wait for another 5 seconds as the sleep time already elapsed (it's the wall clock time). – maaartinus Feb 04 '20 at 15:44
  • 1
    @maaartinus this does make sense. 1) I agree on the safepoint poll (but I have not seen the code to be sure, though I see zero reasons to do it otherwise) 2) and I _really_ wanted to type `15` in there, but too late to edit now. – Eugene Feb 04 '20 at 16:03
  • 2
    @MuhammadGelbana that picture of a freezing hourglass is entirely wrong. The implementation details actually don’t matter. You should understand that a sleeping thread *does nothing*, hence, can’t be stopped while sleeping, as there is no activity to stop. When the GC stops all running threads, the sleeping thread simply isn’t there. – Holger Feb 04 '20 at 18:14
  • 1
    @MuhammadGelbana, it is not a *wake time* that is calculated. Rather, it is (as if) a time before which the thread must not wake that is calculated. That a thread must not run because that time has not yet arrived is separate and independent from any other factor, such as GC, that may also dictate that the thread must not run. That does not imply that the times are cumulative. – John Bollinger Feb 04 '20 at 23:11