RFR (XS): 8188877: Improper synchronization in offer_termination

White, Derek Derek.White at cavium.com
Wed Nov 29 14:01:19 UTC 2017

Hi Andrew,

> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Wednesday, November 29, 2017 5:24 AM
> To: White, Derek <Derek.White at cavium.com>; Andrew Dinn
> <adinn at redhat.com>; Thomas Schatzl <thomas.schatzl at oracle.com>; Kim
> Barrett <kim.barrett at oracle.com>
> Cc: hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR (XS): 8188877: Improper synchronization in
> offer_termination
> On 28/11/17 21:11, White, Derek wrote:
> > Offer-termination just has a simple for-loop that delays some number of
> cycles. As high as 4k iterations * 140 cycles (per SpinPause() on x86), could be
> 573,000 cycles or so. For this case, especially where the termination test is a
> simple load, I think we should test _offered_termination in the spin-wait.
> This should have low overhead on the spinning thread and impose no impact
> on other threads.
> Please point to the exact lines of code you're talking about.

taskqueue.cpp, in offer_termination(), about line 209:

          for (uint j = 0; j < hard_spin_limit; j++) {

hard_spin_limit ranges from 4..4096.

SpinPause() on intel is "pause" (no surprise).

Pause is up to 140 cycles on SkyLake and above (up from 10 cycles).
"Intel® 64 and IA-32 Architectures Optimization Reference Manual", Sect 8.4.7.

 - Derek

More information about the hotspot-gc-dev mailing list