Thinking about how to make Go memory safe without using atomics everywhere: 1. Double bounds check slice indexing: i.e. store length of backing store on heap and check it. 2. Box interface types on heap. 3. Implement maps in Go with no unsafe. I think this works?
-
Show this thread
-
-
Don't they just have locks on everything?
1 reply 0 retweets 0 likes -
Replying to @amccreight @kripken
No. They carefully ensure that slicing can never occur because arrays and interfaces are just one word. Go could have done this but was sloppy.
2 replies 0 retweets 4 likes -
Replying to @pcwalton @amccreight
Hmm, not sure how you fit a pointer+size into a word? Or is that on the heap? Can't you race on accessing the heap data too? (sorry if this is obvious, I know nothing about Java/CLR)
1 reply 0 retweets 0 likes -
Replying to @kripken @amccreight
The only array-like object in Java is an array, which is represented as a pointer to a (length, elements…) structure in memory. You can’t directly take an interior pointer to an element of the array. So you can always dereference the pointer to find the length.
1 reply 0 retweets 3 likes -
Arrays can never change size in Java. But there’s a library type called ArrayList that implements growable arrays on top of the basic primitive, by reallocating the underlying backing store as necessary.
1 reply 0 retweets 2 likes
So there’s no way for the length to become out of sync unless the array storage itself were to be deallocated and reallocated, but that can only happen during the sweep phase of GC, which guarantees no more pointers to the array by construction and therefore no races.
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.