RFR(XL): 8203469: Faster safepoints

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Feb 8 22:37:17 UTC 2019


Robbin,

Because this is a completely different way of solving this problem, I don't
think I can review this incrementally. That means another crawl through
review and might even mean another round of whiteboard diagrams...

A proper review will obviously take me longer than I planned, but I wanted
you know that I'm starting to look at it from the beginning... :-)

Dan


On 2/7/19 11:05 AM, Robbin Ehn wrote:
> But there is a 'better' way.
> Before I added the more graceful "_vm_wait->wait();" semaphore in the 
> while
> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same
> back-off as the rolling forward loop. It turns out that we mostly 
> never spin
> here at all, when all java threads are stop the callbacks is often 
> already done.
> So the addition of the semaphore have no impact on our benchmarks and 
> is mostly
> unused. This is because most threads are in java which we need to 
> spin-wait
> since they can elide into native without doing a callback. My proposed 
> re-base
> removes the the callbacks completely and let the vm thread do all thread
> accounting. All that the stopping threads needs to do is write state and
> safepoint id, everything else is handle by the vm thread. We trade 2 
> atomics +
> a local store per thread against doing 2 stores per thread by the vm 
> thread.
> This makes it possible for a thread in vm to transition into blocked 
> WITHOUT
> safepoint poll. Just set thread_blocked and promise to do safepoint 
> poll when
> leaving that state.
>
> v06_2
> Full:
> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/
> Inc against v05:
> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/
> Inc against v06_1:
> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/
>
> v06_2 simplifies and removes ~200 LOC with same performance.
> If there is a case with a thread in vm taking long time, it will already
> screw-up latency and thus should be fixed regardless of v06_1 vs 
> v06_2. So I
> see no reason why we should not push v06_2.
>
> Passes stress test and t1-5.
>
> Thanks, Robbin



More information about the hotspot-dev mailing list