RFR: jsr166 jdk9 integration wave 6

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Martin Buchholz" <martinrb at google.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Doug Lea" <dl at cs.oswego.edu>, "Paul Sandoz"
> <paul.sandoz at oracle.com>, "Chris Hegarty" <chris.hegarty at oracle.com>, "David Holmes" <David.Holmes at oracle.com>
> Envoyé: Dimanche 3 Avril 2016 23:08:50
> Objet: Re: RFR: jsr166 jdk9 integration wave 6
> 
> Thanks for the review!
> 
> On Sun, Apr 3, 2016 at 12:34 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> > Hi Martin,
> > for
> > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/
> >
> > aka introducing a new constructor seems to be a regression to me,
> > the less overloads we have the better i understand the code.
> 
> For "telescoping constructors" and a parameter that's almost always
> null, I disagree.

if the parameter is often null, maybe the constructor with 4 parameters is useless, and next should be set explicitly in the few cases it's needed.

> There's also the fear that the VM won't optimize away useless volatile
> write to next.

I've seen the bug [1] reported by Aleksey about Hotspot not being able to remove volatile writes with null in constructor.
Here the code is different because val is also a volatile field, and written just before next,
so the VM should be able to coalesce two volatile writes, if the VM is not able to do that, it's another bug.

Nevertheless, we should only optimize to for the usual cases, so we should only have one constructor that doesn't set next.

[...]

[1] https://bugs.openjdk.java.net/browse/JDK-8145948

Rémi