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

[Man Cao]

Thanks for the clarification. I have pushed this change, but I have created
and sent out RFR for https://bugs.openjdk.java.net/browse/JDK-8223227.

-Man


On Wed, May 1, 2019 at 7:42 PM David Holmes <david.holmes at oracle.com> 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/20190501/fa867e9c/attachment.html>