Hacker News Reader

Comment by DarkNova6 | Hacker News Reader

Unless CPU instructions become widespread that allow to process 128 bits in one step, then yes. Java will have the same limitations as any other language. Other languages simply don't make this explicit.

View on HN

IIUC value objects can have any size, it's just that 'reference flattening' requires the object to fit into a machine word. But this is only due to how Java represents object references and its atomicity guarantees.

Naturally, a language that properly supports value semantics does not have any of these limitations.

Java has the mantra of "Integrity by default" which means you can tear into non-integral value type with a flag.

This is the strength of Valhalla. Instead of a binary object/value choice you have different levels of semantic guarantees that will give you better performance characteristics, depending on what your type will be able to give up.

You can have tearability for a complex/quaternion number without problem. But if you have something such as a Range-type class, that gets more problematic because cross-field constraints can be violated.

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.

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.

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.

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.

The Java way was always to let library designers decide how a type is used. I personally think this is the sensible one.

What is terability in this context? Not a Java expert but 20 years coding and did not hear of this.

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-...

We've had MMX for a while now, I don't think we need to wait much longer.

I don't really see why you would need specific hardware to express a type in a programming language, though.

Not for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.

That being said, x86_64 has supported 128-bit atomic writes via cmpxchg16b for over a decade. Modern 64-bit ARM has several ways to do them as well.

Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)

cmpxchg16b can only handle 64bits data correctly because of ABA problem.

It's about the semantic guarantees because you don't want to introduce a parallel programming bug just because you added a field to a type. Tearability is opt in and if you are serious about performance you will make the correct choice.

It's mostly a performance question in order to adhere to Java's memory model.

You can deliberately opt out of it though and for such a mainstream language such as Java, this just might be the sane choice.

But if I don't care for object atomicity, can I get struct-like behaviour in Java for arbitrary large types?

From elsewhere I've seen that this is something they are thinking about offering but nothing concrete has surfaced. It would be an opt-in sort of thing where you say "I'm ok with my code breaking if I misuse this class".

It will likely require you poke in the `jdk.internal` package space.

Reply on news.ycombinator.com