Final Freeze & Inheritance

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Final Freeze & Inheritance

thurstonn
Given the following understanding:

class SafelyInitialized
{
   int x;
   final int y;

   SafelyInitialized(int i)
   {
       this.y = i;
       this.x = i
   }

}

is  de facto a class safe for initialization (de facto because it's not formally prescribed by the JMM, but all JVM implementations provide such a 'guarantee', per A. Shipilev).

What about this?

class Maybe extends SafelyInitialized
{
      int z;
      Maybe(int i)
      {
          super(i);
          this.z = i
      }


}

My inference is No, Maybe is not a class safe for initialization (i.e. maybe.z can evaluate 0), but it's not clear to me.

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

Remi Forax
----- Mail original -----
> De: "thurstonn" <[hidden email]>
> À: [hidden email]
> Envoyé: Mercredi 18 Janvier 2017 19:45:10
> Objet: [concurrency-interest] Final Freeze & Inheritance

> Given the following understanding:
>
> class SafelyInitialized
> {
>   int x;
>   final int y;
>
>   SafelyInitialized(int i)
>   {
>       this.y = i;
>       this.x = i
>   }
>
> }
>
> is  /de facto/ a class safe for initialization (de facto because it's not
> formally prescribed by the JMM, but all JVM implementations provide such a
> 'guarantee', per A. Shipilev).

Today all known implementations have a stronger guarantee, but tomorrow ???
I've hard time to understand why are you making a bet that no JVM will change in the future.

Rémi
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

Vitaly Davidovich
It's Java, we know the implementation precedent trumps the spec - spec is adjusted to match implementation :).

But, I don't see why inheritance matters here.
On Wed, Jan 18, 2017 at 3:52 PM Remi Forax <[hidden email]> wrote:
----- Mail original -----

> De: "thurstonn" <[hidden email]>

> À: [hidden email]

> Envoyé: Mercredi 18 Janvier 2017 19:45:10

> Objet: [concurrency-interest] Final Freeze & Inheritance



> Given the following understanding:

>

> class SafelyInitialized

> {

>   int x;

>   final int y;

>

>   SafelyInitialized(int i)

>   {

>       this.y = i;

>       this.x = i

>   }

>

> }

>

> is  /de facto/ a class safe for initialization (de facto because it's not

> formally prescribed by the JMM, but all JVM implementations provide such a

> 'guarantee', per A. Shipilev).



Today all known implementations have a stronger guarantee, but tomorrow ???

I've hard time to understand why are you making a bet that no JVM will change in the future.



Rémi

_______________________________________________

Concurrency-interest mailing list

[hidden email]

http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
Sent from my phone

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

thurstonn
Vitaly Davidovich wrote
It's Java, we know the implementation precedent trumps the spec - spec is
adjusted to match implementation :).

But, I don't see why inheritance matters here.
On Wed, Jan 18, 2017 at 3:52 PM Remi Forax <[hidden email]> wrote:
Well, it might matter if there is only a single fence emitted, and it's directly after the SafelyInitialized constructor, so:

super()
STORESTORE
this.z = i
publish (unsafely) Maybe instance

wouldn't prevent another thread from reading 0 for maybe.z

Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

Vitaly Davidovich
I'd imagine (expect, really) it's the entire object construction that gets the freeze, irrespective of how many super ctors are called in the process.

On Wed, Jan 18, 2017 at 2:37 PM, thurstonn <[hidden email]> wrote:
Vitaly Davidovich wrote
> It's Java, we know the implementation precedent trumps the spec - spec is
> adjusted to match implementation :).
>
> But, I don't see why inheritance matters here.
> On Wed, Jan 18, 2017 at 3:52 PM Remi Forax &lt;

> forax@

> &gt; wrote:

Well, it might matter if there is only a single fence emitted, and it's
directly after the SafelyInitialized constructor, so:

super()
STORESTORE
this.z = i
publish (unsafely) Maybe instance

wouldn't prevent another thread from reading 0 for maybe.z





--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Final-Freeze-Inheritance-tp13925p13928.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

Alex Otenko
I’d imagine it is only the final field store that gets the freeze, so whatever happens after it in program order is not safely constructed.

In this case the initialization of x is not safe.

Alex


On 18 Jan 2017, at 21:28, Vitaly Davidovich <[hidden email]> wrote:

I'd imagine (expect, really) it's the entire object construction that gets the freeze, irrespective of how many super ctors are called in the process.

On Wed, Jan 18, 2017 at 2:37 PM, thurstonn <[hidden email]> wrote:
Vitaly Davidovich wrote
> It's Java, we know the implementation precedent trumps the spec - spec is
> adjusted to match implementation :).
>
> But, I don't see why inheritance matters here.
> On Wed, Jan 18, 2017 at 3:52 PM Remi Forax &lt;

> forax@

> &gt; wrote:

Well, it might matter if there is only a single fence emitted, and it's
directly after the SafelyInitialized constructor, so:

super()
STORESTORE
this.z = i
publish (unsafely) Maybe instance

wouldn't prevent another thread from reading 0 for maybe.z





--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/Final-Freeze-Inheritance-tp13925p13928.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

Andrew Haley
On 19/01/17 09:58, Alex Otenko wrote:

> I’d imagine it is only the final field store that gets the freeze,
> so whatever happens after it in program order is not safely
> constructed.
>
> In this case the initialization of x is not safe.

Yes, exactly.  I have considered using STLR for writing to final
fields on AArch64, but it's not really an optimization so I didn't.

Andrew.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Final Freeze & Inheritance

Aleksey Shipilev-3
In reply to this post by thurstonn
On 01/18/2017 07:45 PM, thurstonn wrote:

> Given the following understanding:
>
> class SafelyInitialized
> {
>    int x;
>    final int y;
>
>    SafelyInitialized(int i)
>    {
>        this.y = i;
>        this.x = i
>    }
>
> }
>
> is  /de facto/ a class safe for initialization (de facto because it's not
> formally prescribed by the JMM, but all JVM implementations provide such a
> 'guarantee', per A. Shipilev).
This is a good learning exercise about separating the language spec requirements
and implementation details.

I usually say that *Hotspot* VM *happens* to make it stronger by emitting the
barrier after all fields inits, on the exit path from constructor. We can't
vouch for all VMs in the world with all cases.

You can plausibly either do the barrier right after the final field store, or
even emit some "special" store instruction with needed semantics just for that
final field. Both will expose non-final "x" to the racy behavior, as per spec.
(Part of the reason is the final field semantic rule from 17.5.1 requires to
read *through* the final field on the reader side to get any effect on the
outcome -- so reading/writing plain fields without dependent final fields in the
middle is not affected by any freeze action).

Probably even scarier example that I saw in the wild is that Johnny uses "x"
happily with no problems, and then Billy removes "final" from _another_ field in
an irrelevant changeset -- oops. Friends don't let friends to piggyback on
finality of irrelevant fields.

> What about this?
>
> class Maybe extends SafelyInitialized
> {
>       int z;
>       Maybe(int i)
>       {
>           super(i);
>           this.z = i
>       }
>
>
> }
>
> My inference is *No*, Maybe is not a class safe for initialization (i.e.
> maybe.z can evaluate 0), but it's not clear to me.
Since the first case above is not safe, this is not safe either.

-Aleksey


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (836 bytes) Download Attachment