RFR 8215047: Task terminators do not complete termination in consistent state
Thomas Schatzl
thomas.schatzl at oracle.com
Fri Jan 25 10:15:38 UTC 2019
Hi,
On Wed, 2019-01-23 at 09:32 -0500, zgu at redhat.com wrote:
> Hi Thomas,
>
> Thanks for getting the review started.
>
> > initial comments:
> >
> > - taskqueue.hpp: I recommend adding an empty virtual destructor in
> > any
> > case.
> >
> > - owstTaskTerminator.cpp:69: s/returnning/returning/
> >
>
> Updated based on your comments:
>
> http://cr.openjdk.java.net/~zgu/JDK-8215047/webrev.01/index.html
>
> Thanks,
>
> -Zhengyu
>
> > I will think a bit more about the change while waiting for the test
> > results.
> >
Testing showed good results, no issues.
I would like to ask if I understood the changes correctly: to me it
seems that some of these changes are the actual fix, others seem to be
enhancements.
So the changes in owstTaskTerminator.cpp:68-74 seem to be the actual
fix for the issue - it needs to recheck _offered_termination within the
lock at that point because of the mentioned race.
There are additional improvements to both terminators
(owstTaskTerminator.cpp:171-174, taskqueue.cpp:220-232) that may result
in potential needless additional rounds of offer_termination().
I.e. before returning a result that indicates to the caller to continue
doing work for another round, instead if in the meantime everyone has
offered termination, we are obviously done too.
If I am correct, I would strongly prefer if these changes (the
enhancements) would be changed separately.
Also, the code in taskqueue.cpp:220-232 is worth an extra method with a
description indicating why we can return true in offer_termination in
that case (because obviously, if all threads are sure to have offered
termination, between the evaluation of the condition and trying to
decrement the _offer_termination variable, work has been completed.
As an additional enhancement, it might be worth doing padding of the
ParallelTaskTerminator::_offered_termination variable.
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list