RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking

[Man Cao]

No worries. This helps clarify the naming practices so we are on the same
page in the future.

-Man


On Thu, May 2, 2019 at 12:30 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:

> Hi David and Nan,
>
> Sorry, my suggestion was not aligned with usual practice and added some
> extra work. :(
>
> Thanks,
> Serguei
>
>
> On 5/1/19 19:42, David Holmes wrote:
> > On 2/05/2019 11:00 am, Man Cao wrote:
> >> Thank everyone for the review!
> >> Renamed and final webrev:
> >> https://cr.openjdk.java.net/~manc/8223177/webrev.02/
> >
> > No do not rename! Sorry Serguei but for these accesses with
> > OrderAccess semantics the placement of the acquire/release reflects
> > the barrier semantics of load_acquire and release_store. So we use
> > foo_acquire to load foo with acquire semantics; while release_set_foo
> > performs a release barrier followed by set_foo. This convention is
> > used throughout the VM for these kinds of methods.
> >
> > David
> > -----
> >
> >> -Man
> >>
> >>
> >> On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com
> >> <mailto:serguei.spitsyn at oracle.com> <serguei.spitsyn at oracle.com
> >> <mailto:serguei.spitsyn at oracle.com>> wrote:
> >>
> >>     Hi Man,
> >>
> >>     Looks good to me.
> >>
> >>     Minor comment:
> >>     I'd suggest to rename tag_map_acquire to acquire_tag_map to be
> >>     consistent with release_set_tag_map.
> >>
> >>
> >>     Thanks,
> >>     Serguei
> >>
> >>
> >>     On 4/30/19 18:51, Man Cao wrote:
> >>>     Hi all,
> >>>
> >>>     Can I have reviews for this small change that adds memory fences
> >>>     for double-checked locking?
> >>>     We found this race while working on the Java ThreadSanitizer
> >>> project.
> >>>
> >>>     Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/
> >>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8223177
> >>>
> >>>     -Man
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190502/b8f028b9/attachment.html>