0

My env:

  1. JDK : temurin-1.8.0_332
  2. System: macOS big sur
  3. VM: Hot Spot
  4. GuaranteedSafepointInterval = 1000ms (default)

Q1: The vm param GuaranteedSafepointInterval = 1000ms is really accurately?

    public class Test {

    public static AtomicInteger count = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> {
            for (int i = 0;i < 1000000000;i++){
                count.getAndAdd(1);
            }
            System.out.println(Thread.currentThread().getName() + " done" );
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
        Thread.sleep(1000);
        System.out.println("count result = " + count);

    }
}

As expect,because of the safepoint, the result is

count result = 2000000000
Thread-1 done
Thread-0 done

But ,if change the main thread sleep time to 800ms...(more you can use <800ms) result

So, the default value GuaranteedSafepointInterval = 1000ms is really accurately?

Q2: Sometimes,if i still set sleep time = 1000ms,but change the loop content count.getAndAdd(1) to count.getAndAdd(i) ,the "count result" will print after 1s...... as i know,the hot spot vm(jdk=1.8) does some optimizations for 'Counted Loop' when sets savepoint ,(according to the Q1 scence),why it doesnt effective？

Any Can Help Me? More Thanks...

sssslaver
  • 1
  • 3
    Don’t post text results as screenshot. You’ve already proven to be capable of copying three lines of text, so you surely can do this again. And before you jump on the bandwagon and post a follow-up of [this Q&A](https://stackoverflow.com/q/67068057/2711488), you should fully understand the issue. Since the issue is that the main thread doesn’t run shorter than the others, the order of the printed lines is irrelevant. Further, two intervals of the same length but arbitrary starting point are very likely but not guaranteed to overlap. And what effect of counted loop optimizations did you expect? – Holger Sep 09 '22 at 12:25
  • you forgot to mention `-XX:+UnlockDiagnosticVMOptions`, without which `GuaranteedSafepointInterval` is not even an editable option. And you might get more insights by reading [this](https://stackoverflow.com/questions/67068057/the-main-thread-exceeds-the-set-sleep-time/67075064) – Eugene Sep 09 '22 at 13:33
  • @Holger Sorry for my first question on stackoverflow with unclear description ... – sssslaver Sep 10 '22 at 15:22
  • @Holger Of course i have red [the Q&A](https://stackoverflow.com/questions/67068057/the-main-thread-exceeds-the-set-sleep-time) you mentioned , what i want to ask with my Q1 is if i set main thread sleep time to 800ms, the "count result = " still print until other two sub thread finished, so what caused this happend? – sssslaver Sep 10 '22 at 15:39
  • @Holger And my Q2 is if i still run this code with only change the loop content "count.getAndAdd(1)" to "count.getAndAdd(i)" ,it happend occasionally that the main thread will not wait for the end of the sub-thread – sssslaver Sep 10 '22 at 15:57
  • 1
    It doesn’t matter, how small you make the sleep time, as long as it is non-zero, there is a non-zero chance to overlap with a safepoint. As said, even if the sleep time matches the safepoint interval, there is no guaranty to overlap, but only a *very high chance*. This has nothing to do with using `getAndAdd(1)` or `getAndAdd(i)`, this is just coincidence. Any change can have a subtle influence on the timing. Only when the sleep time is larger than the safepoint interval (“*subject to the precision and accuracy of system timers*”), you can be sure to always hit a safepoint during the sleep. – Holger Sep 12 '22 at 09:05
  • @Holger，so you meant that the -XX:GuaranteedSafepointInterval = 1000ms is not the fixed time while vm executing the safepoint checking actually? what cause this happened , CPU or ....? – sssslaver Sep 13 '22 at 03:36
  • 1
    A safepoint may be triggered by any of the operations listed in [this answer](https://stackoverflow.com/a/29673564/2711488). The `GuaranteedSafepointInterval` specifies how much time will elapse after a safepoint before the next, when no other trigger exists. But even when no other trigger exists during the `sleep`, you don’t know the time of the last safepoint before the `sleep`, hence, you can not predict the next time. If you enter `sleep` when the last safepoint was 900ms ago, you’d have to `sleep` less than 100ms to miss the next. – Holger Sep 13 '22 at 07:17

0 Answers0