Hacker News Reader

Comment by jeroenhd | Hacker News Reader

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.

Reply on news.ycombinator.com