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++) {
SpinPause();
}
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