On 04/29/2017 07:12 PM, Aleksey Shipilev wrote: > On 04/29/2017 06:56 PM, Aleksey Shipilev wrote: >> On 04/29/2017 04:56 PM, J Crawford wrote: >>> The mystery boils down to: >>> >>> "/The exact same block of code becomes slower after a busy spin pause./" >>> >>> I posted a short source code that *unequivocally* proves and demonstrates >>> the >>> problem: >>> http://stackoverflow.com/questions/43696948/why-does-the-jvm-show-more-latency-for-the-same-block-of-code-after-a-busy-spin >> >> I don't think this is much of the mystery, because wakeup from a long sleep >> causes gradual transition from low power/frequency/scheduling states to >> higher >> ones. >> >> This is clearly visible if you do several consecutive operations after the >> sleep, e.g. by adding this: >> >> while(count < results.length) { >> + if ((count & 7) > 0) interval = 0; >> double x = busyPause(interval); > > Ah, I misread the test. busyPause is not powering down anything. What's > weirder, > the first pair of nanoTime calls after exiting busyPause is hiccuping even > without calculations in between.
Still flying in blind for fun, trying different things: http://cr.openjdk.java.net/~shade/scratch/JvmPauseLatency.java a) "Warming up" both branches in busyPause seems to help first hiccup. Notice that with small interval one of the loop branches would be non-taken, and C2 would put a trap there, blowing up on first access. So much for "avoiding the deoptimization"... b) Inlining busyPause seems to help to avoid every hiccup but the first. I wonder if this is actually the machine effect when e.g. the branch mispredict on loop exit that faces unusual code shape ("ret" from uninlined method?) makes the lag worse. When method is inlined, only the first trap would introduce lag, not any subsequent one. At this point you want to dive into the generated code, and there JMH perfasm is your friend. -Aleksey -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
