> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access).
I really hope they give an escape hatch for this. It will make it really hard to extract a lot of the benefit of valhala if you can't make a thread unsafe value class. It's also one of those problems that will be quite hard to run into. You basically need something like this
class Bar {
static Foo value[] = new Foo[10];
static void setFooFromManyThreads(Foo foo) {
value[0] = foo;
}
value record Foo(int x, int y, int z) {};
}
Not something you typically run into and generally already a thread safety problem.
The solution is also simple, a `synchronized{}` block will fix it if you need to have a tearable class that's written from multiple threads.
But the other thing is that for SIMD operations, you really need flattening, and that really does typically mean having something like `Foo(double x, double y, double z)` in play. It'd be a shame if the way we have to do this is a struct of arrays.
I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway? And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)
The problem is concurrent access. A write bit on the value doesn't really help as you have to check and update the bit using atomic instructions. But you'd also need to reserve that bit for every read as concurrent access wouldn't be safe.
That's the tearing problem.
It gets worse because things you can't generally do in the JVM can happen. For example, if your value class contains a reference to an object but that reference just so happens to split a tear, it's possible one thread to see an invalid reference while another thread is writing that object. That could be fixed with some added padding based on the architecture to make sure stored references aren't tearable.
References can't tear in Java, per the specification (long and double could actually, the spec only talks about references and 32-bit slots being tear-free - though actually almost all implementations have them atomic as it's practically free on 64-bit CPUs). That would basically make the platform memory unsafe so I'm fairly sure they would make sure references are always written atomically.
But tearing may still cause a logical issue of course. (Think of a date class where the day may still be 31 but the month was set to Feb on another thread).
Interestingly Go is memory unsafe on this issue, slices can tear and later code can read into an incorrect offset from the pointer. Java abstracts away pointers, so this issue is non-existant there.
I really hope they give an escape hatch for this. It will make it really hard to extract a lot of the benefit of valhala if you can't make a thread unsafe value class. It's also one of those problems that will be quite hard to run into. You basically need something like this
Not something you typically run into and generally already a thread safety problem.The solution is also simple, a `synchronized{}` block will fix it if you need to have a tearable class that's written from multiple threads.
But the other thing is that for SIMD operations, you really need flattening, and that really does typically mean having something like `Foo(double x, double y, double z)` in play. It'd be a shame if the way we have to do this is a struct of arrays.