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.

▲

muvlon 3 days ago | parent [-]

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?)

	▲	Coelacanthus a day ago \| parent [-]
		cmpxchg16b can only handle 64bits data correctly because of ABA problem.

▲

DarkNova6 3 days ago | parent | prev | next [-]

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.

▲

my-next-account 3 days ago | parent | prev [-]

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

	▲	DarkNova6 3 days ago \| parent [-]
		You can deliberately opt out of it though and for such a mainstream language such as Java, this just might be the sane choice.