RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

Paul Sandoz paul.sandoz at oracle.com
Wed Aug 24 21:29:51 UTC 2016


> On 24 Aug 2016, at 14:17, Martin Buchholz <martinrb at google.com> wrote:
> 
> Hi Paul,
> 
> Thanks for doing this.
> 
> Probably your IDE is fixing import statements.  We'd prefer having that not happen for j.u.c. but we can live with it.
> 

Ah, i will update so as not to perturb that.


> Of course, keeping all the variants in sync is errorprone.  Below is one case where what you're testing and what your assertions say are out of sync.  In such cases I've found it better to simply do:
> 
> assertTrue(success);
> assertEquals(x, 1.0d);
> 
> which is more maintainable.  In case of a failure the ever helpful stack trace will let us know what went wrong.
> 

Ooops, i will fix that. We have found it useful to output method to more quickly identify what is failing. It’s usually not a lot of work because the source is modified in the test templates, but you are correct in saying it is not so easy to maintain.

Thanks for the review.

—

It just so happens i am blocked on a x86 byte CAS fix in HotSpot making it’s way into jdk9/dev and on the order of patches in my queue (i could rebase,  but that is more work). So it may be a week or two before i commit.

Paul.

> @@ -749,9 +749,9 @@
>              for (int c = 0; c < WEAK_ATTEMPTS && !success; c++) {
>                  success = vh.weakCompareAndSetRelease(2.0d, 1.0d);
>              }
> -            assertEquals(success, true, "weakCompareAndSetVolatile double");
> +            assertEquals(success, true, "weakCompareAndSet double");
>              double x = (double) vh.get();
> -            assertEquals(x, 1.0d, "weakCompareAndSetVolatile double");
> +            assertEquals(x, 1.0d, "weakCompareAndSet double");
>          }
> 
>          // Compare set and get
> 
> 
> On Wed, Aug 24, 2016 at 8:45 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> Hi,
> 
> Gentle reminder.
> 
> Paul.
> 
> > On 10 Aug 2016, at 17:03, Paul Sandoz <Paul.Sandoz at oracle.com <mailto:Paul.Sandoz at oracle.com>> wrote:
> >
> > Hi
> >
> > Please review:
> >
> >  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/> <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/>>
> >
> > This is a refactoring to produce a consistent naming scheme for the VarHandle Read Modify Write (RMW) methods. The unqualified methods default to volatile access.
> >
> > (And i hope this is the last modifying to the API signatures)
> >
> > This touches 166 classes that use or refer to the weak plain/volatile methods.
> >
> > The plan is to follow up deprecating (*not* for removal) the weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add  weakCompareAndSetPlain methods. Analysis via grepcode shows very little usages of the Atomic*.weakCompareAndSet methods.
> >
> > A further plan is to rename the Unsafe methods s/Swap/Set, add Plain qualifier etc.
> >
> > Paul.
> 
> 



More information about the core-libs-dev mailing list