Hacker News new | ask | show | jobs
by Smaug123 1 day ago
I don’t understand this comment - the .NET CLR supports arbitrarily large value types. Are you referring to something like “atomic flattening of those types” instead? Because the CLR doesn’t guarantee that, and therefore supports flattening.
2 comments
pwagland 1 day ago
That is exact problem.

Basically JEP401 guarantees that just adding "value" to the class won't change behaviour, which also means that you are not allowed to see object tearing, which requires atomic operations on the field.

Relaxing that would break safe publication rules, at least for Java.

link
DarkNova6 1 day ago
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform.

This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.

link
joe_mwangi 1 day ago
Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.
link
DarkNova6 22 hours ago
The Java way was always to let library designers decide how a type is used. I personally think this is the sensible one.
link
germandiago 1 day ago
What is terability in this context? Not a Java expert but 20 years coding and did not hear of this.
link
alasr 1 day ago
From Valhalla's design notes[0]:

> For the primitive types longer than 32 bits (long and double), it is not guaranteed that reads and writes from different threads (without suitable coordination) are atomic with respect to each other. The result is that, if accessed under data race, a long or double field or array component can be seen to “tear”, where a read might see the low 32 bits of one write, and the high 32 bits of another. (Declaring the containing field volatile is sufficient to restore atomicity, as is properly coordinating with locks or other concurrency control.)

... ...

[0] - https://openjdk.org/projects/valhalla/design-notes/state-of-...

link