RFR: 8210889: Some service thread cleanups can be starved
kim.barrett at oracle.com
Thu Sep 20 03:17:26 UTC 2018
> On Sep 19, 2018, at 9:04 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 20/09/2018 5:34 AM, Kim Barrett wrote:
>>> On Sep 19, 2018, at 3:32 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>> On Tue, 2018-09-18 at 20:46 -0400, Kim Barrett wrote:
>>>> Please review this small change to the ServiceThread. When checking
>>>> for work to be done, rather than immediately doing the first kind of
>>>> work found, instead determine all pending work and then do all known
>>>> pending work. This avoids the possibility of frequently available
>>>> work early in the sequence of checks from leading to starvation of
>>>> work associated with later checks.
>>> Looks good. Maybe the comment could be improved because it does not
>>> answer why we do not want short-circuiting in this case. It only seems
>>> to describe what the code does.
>> Sure, I can do that:
>> // Process all available work on each (outer) iteration, rather than
>> // only the first recognized bit of work, to avoid frequently true early
>> // tests from potentially starving later work. Hence the use of
>> // arithmetic-or to combine results; we don't want short-circuiting.
> I was going to ask about the "== 0" rather than "== false", but I assume | is always a bitwise-or even for bool rather than just being a non-short-circuiting-or.
Correct, it’s a bitwise-or of promoted to int values with an int result.
And if the result had been bool I’d have applied operator! rather than comparing to false.
> Of course now you have fixed this the operations previously getting preferential treatment may exhibit additional latency. ;-)
>> Thanks for reviewing.
More information about the hotspot-runtime-dev