RFR: 8210889: Some service thread cleanups can be starved

Kim Barrett 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:
>>> Hi,
>>> 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.
>>> Thanks,
>>>  Thomas
>> 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. ;-)
> Cheers,
> David
>> Thanks for reviewing.

More information about the hotspot-runtime-dev mailing list