4 ms·
FWIW, I meant race semantics similar to Java's--weird things happen but type/memory safety remains. Not the whole Java runtime model with object headers, etc.
by twotwotwo 5y ago
FWIW, I meant race semantics similar to Java's--weird things happen but type/memory safety remains. Not the whole Java runtime model with object headers, etc.
It's obviously, uh, quite an Exercise for the Reader(tm) to figure out the best path to avoid memory unsafety given races in line with other Go priorities (as a starting point, imagine a ton of expensive atomics accessing certain pairs on the heap, downgraded to regular loads/stores if the compiler can prove it's safe). But I was trying to say it seems harder to get there now that certain things are set in stone and regressing perf of anything is going to be bad for some user out there.
- throwaway34241 5y agoSure, I was imagining implementing better race semantics the way Java/C# do, by referencing certain multi-word data by pointer to avoid partial update problems. As it is now slices are 192-bit values (on 64 bit systems) embedded directly in objects that can be shared across threads, I don't know how you would efficiently update that atomically.
- twotwotwo 5y agoJust in theory: pointer/capacity pair is atomic, then you read len non-atomically and check it's less than cap before using it. Slice header today puts len before cap, but, like, if we're dreaming. You'd probably hit other walls. I'm def. not trying to say it's straightforward!
- uluyol 5y agoIs Java really memory safe in the face of races? The case I'm thinking about is this: Shared state: ArrayList A with intial buffer B and length L Thread 1: Grows A and replaces B with buffer C, length with M Thread 2: (Earlier loaded B into a register) Code says write to A[M-1]. JVM checks M-1 against M but uses B as it was already stored in a register. Now you have a buffer overflow. Except, people on this thread seem to think this is impossible. How does Java prevent this?