RFR(XS) for PeriodicTask_lock cleanup (8072439)

[Carsten Varming]

Dear Daniel,

Looks good to me.

The line: "OrderAccess::fence();  // ensure WatcherThread sees update in
main loop" seems unnecessary as the lock acts as a memory barrier.

Carsten

On Tue, Feb 17, 2015 at 4:44 PM, Daniel D. Daugherty <
daniel.daugherty at oracle.com> wrote:

> Greetings,
>
> My fix for the following bug:
>
>     JDK-8047720 Xprof hangs on Solaris
>
> that was pushed to JDK9 last June needs to be cleaned up.
>
> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten
> Varming (varming at gmail.com) for reporting the mess that I made
> in WatcherThread::stop() and for suggesting fixes.
>
> This code review is for a general cleanup pass on PeriodicTask_lock
> and some of the surrounding code. This is a targeted review in that
> I would like to hear from three groups of people:
>
> 1) The author and reviewers for:
>
>    JDK-7127792 Add the ability to change an existing PeriodicTask's
>                execution interval
>
>    Rickard, David H, and Markus G.
>
> 2) The reviewers for:
>
>    JDK-8047720 Xprof hangs on Solaris
>
>    Markus G and Coleen
>
> 3) Alex and Carsten
>
>
> Here's the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/
>
> I've attached the original RFR for JDK-8047720 that explains
> the original deadlock that was being fixed. Similar testing
> will be done with this fix.
>
> Dan
>