And the big limitation is the rule that object writes can't tear - while this remains in place, it means that only tiny value classes will get any of the performance advantages being discussed, on regular processors. Specifically, the largest guaranteed atomic norma read/write in x86-64 is 64 bits, so any class that is larger than that (say, a pair of longs, or even a pair of ints until we get non-nullability) will not be compactible. An array of 1M (long, long) pairs will hold 1M pointers to (long, long) pairs allocated in the GC heap, forever. An array of 1M (int, int) pairs will as well, but in some future release when non-nullability makes it in, it will actually work as hoped.
Torn reads are probably coming as a separate attribute to opt-in. It's technically already there but not stable, and I don't think it does anything yet to unbox values on fields/arrays.
Right, I didn't mean those are bad things! Just that value classes don't change the semantics of regular objects as much as value semantics do in other language. I like that the remaining features will be orthogonal and opt-in.
Go isn't even memory-safe under data races, because they don't want to pick between slower loads (like .NET's Memory<T>.Span) or removing fat pointers. Meanwhile the JVM never had value types until now so they'd silently break a lot of code if a single keyword applied willy-nilly introduced torn reads like struct does in C#. It's coming but as a separate opt-in.
Comments
Nullability is coming later, and already with Panama you have plenty of room to do C like stuff.
Go isn't much better.
You probably mean non-nullability.
And the big limitation is the rule that object writes can't tear - while this remains in place, it means that only tiny value classes will get any of the performance advantages being discussed, on regular processors. Specifically, the largest guaranteed atomic norma read/write in x86-64 is 64 bits, so any class that is larger than that (say, a pair of longs, or even a pair of ints until we get non-nullability) will not be compactible. An array of 1M (long, long) pairs will hold 1M pointers to (long, long) pairs allocated in the GC heap, forever. An array of 1M (int, int) pairs will as well, but in some future release when non-nullability makes it in, it will actually work as hoped.
Torn reads are probably coming as a separate attribute to opt-in. It's technically already there but not stable, and I don't think it does anything yet to unbox values on fields/arrays.
Right, I didn't mean those are bad things! Just that value classes don't change the semantics of regular objects as much as value semantics do in other language. I like that the remaining features will be orthogonal and opt-in.
Go isn't even memory-safe under data races, because they don't want to pick between slower loads (like .NET's Memory<T>.Span) or removing fat pointers. Meanwhile the JVM never had value types until now so they'd silently break a lot of code if a single keyword applied willy-nilly introduced torn reads like struct does in C#. It's coming but as a separate opt-in.