4 ms·

> I wonder what you can practically do to mitigate that at this point; doesn't seem like you go back and change things to be like Java. Wouldn't there be an ob

> I wonder what you can practically do to mitigate that at this point; doesn't seem like you go back and change things to be like Java. Wouldn't there be an obvious trade off there, requiring an extra heap allocation and indirection every time a slice is used in a data structure? I've always thought of Go as lower-level than Java (since it has explicit pointers, more control over memory layout, etc), which I think makes it a more useful language overall even if not the best fit for every application (since if you do want Java, it already exists and is mature). In other words, I think both Java's and Go's decisions make sense here.

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 ago
  Sure, 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 ago
    Just 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 ago
  Is 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?
  - lmm 5y ago
    The buffer itself, being a Java array, is checked. You'll get an exception but you won't get undefined behaviour.
    - uluyol 5y ago
      Of course. That makes sense. Thanks!

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 ago
Sure, 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 ago
  Just 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 ago
Is 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?
- lmm 5y ago
  The buffer itself, being a Java array, is checked. You'll get an exception but you won't get undefined behaviour.
  - uluyol 5y ago
    Of course. That makes sense. Thanks!