----- Mail original ----- > De: "Martin Buchholz" <marti...@google.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "Doug Lea" > <d...@cs.oswego.edu>, "Paul Sandoz" > <paul.san...@oracle.com>, "Chris Hegarty" <chris.hega...@oracle.com>, "David > Holmes" <david.hol...@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 <fo...@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
