Honestly, I believe JMM is *rocket science* and I am not an expert on the subject -- which is also apparent from my wrong alarm. That being said, these materials might get you warmed up:
- TSM01-J. Do not let the this reference escape during object construction <https://www.securecoding.cert.org/confluence/display/java/TSM01-J.+Do+not+let+the+this+reference+escape+during+object+construction> - TSM03-J. Do not publish partially initialized objects <https://www.securecoding.cert.org/confluence/display/java/TSM03-J.+Do+not+publish+partially+initialized+objects> - Safe Object Publication in Java <http://vlkan.com/blog/post/2014/02/14/java-safe-publication/> - Safe Publication and Safe Initialization in Java <http://shipilev.net/blog/2014/safe-public-construction/> Let me briefly explain what I understand from the Pattern class issue: class A { final int x, y; A(int x) { this.x = x; this.y = f(); } int f() { return x; } } This is totally safe, since "final" fields enforce a happens-before relationship. class A { int x, y; A(int x) { this.x = x; this.y = f(); } int f() { return x; } } This is also safe, because JMM allows optimizations (e.g. assignment re-ordering) such that a single-threaded execution should always produce the same output. class A { static A a; *int* x; A(int x) { this.x = x; a = this; } } This is unsafe, we leaked "this" prior to initialization. Another thread accessing A.a instance might observe an uninitialized x. I think I mis-interpreted the "An object is in a predictable, consistent state only after its constructor returns" statement from JCP book. I will consider this case more thoroughly tomorrow, maybe even write a blog post about it. On Tue, Dec 30, 2014 at 4:31 PM, Reza Naghibi < [email protected]> wrote: > Is this because the JVM may optimize and reorder the code? So I come from > a c and assembly background, just trying to better understand... :) > > > > > <div>-------- Original message --------</div><div>From: Volkan Yazıcı < > [email protected]> </div><div>Date:12/30/2014 9:55 AM (GMT-05:00) > </div><div>To: [email protected] </div><div>Cc: > </div><div>Subject: Re: Pattern.rank </div><div> > </div>You're right Reza, it is not unsafe. I confused it with leaking > "this" in > ctor -- even in that case "final" modifier of the fields impose the > happens-before relationship constraint, which is also fine. It needed quite > some debate on FreeNode to get things resolved. Sorry for the wrong alarm. > > > On Tue, Dec 30, 2014 at 3:04 PM, Reza Naghibi < > [email protected]> wrote: > > > Hmm... can you provide a reference or some kind of example showing that a > > single threaded read after write is unreliable? I'm thinking if this is > > true, huge swaths of programs would be deemed unsafe since read after > write > > is quite a common memory pattern... :) No? > > > > > > > > <div>-------- Original message --------</div><div>From: Volkan Yazıcı < > > [email protected]> </div><div>Date:12/30/2014 8:31 AM > (GMT-05:00) > > </div><div>To: [email protected] </div><div>Cc: > > </div><div>Subject: Re: Pattern.rank </div><div> > > </div>A related excerpt from the Java Concurrency in Practice: "An object > > is in a > > predictable, consistent state only after its constructor returns, ..." In > > its current form of Pattern: > > > > Pattern(...) { > > ... > > this.boost = boost; > > this.rank = rank(); > > } > > > > public long rank() { > > // access to this.boost > > } > > > > > > this.boost might not have been completely initialized when rank() tries > to > > access to it. > > > > On Tue, Dec 30, 2014 at 2:14 PM, Reza Naghibi < > > [email protected]> wrote: > > > > > Interesting... you cannot access instance variables in the constructor? > > > > > > Also, this hasn't been fully implemented. Boost is going to be a DRR > > > pattern attribute which will allow 1 pattern to be configured to rank > > > higher than another. > > > > > > > > > > > > > > > <div>-------- Original message --------</div><div>From: Volkan YAZICI < > > > [email protected]> </div><div>Date:12/30/2014 4:41 AM > > (GMT-05:00) > > > </div><div>To: [email protected] </div><div>Cc: > > > </div><div>Subject: Pattern.rank </div><div> > > > </div>Hi, > > > > > > I have an objection and a question about Pattern class in Java client. > > > > > > *Objection:* Pattern.rank() instance method gets called in ctor and > > > accesses to instance variables, which might not have been initialized > yet > > > due to JMM semantics. I propose to fix it as in DMAP-115 > > > <https://issues.apache.org/jira/browse/DMAP-115>. > > > > > > *Question:* Shall we remove boost option on Pattern ctor? It is neither > > > used, nor available in .NET client. > > > > > > Best. > > > > > >
