4 ms·

Even a smart compiler can't break the program semantics, and without a closed world assumption it simply can't assume that an entirely different part of the pro

Even a smart compiler can't break the program semantics, and without a closed world assumption it simply can't assume that an entirely different part of the program doesn't expect to observe object identity for a type. Java is adding small, orthogonal features that amount to the same feature set as value types in other languages, but can be cherry-picked into existing code for partial advantages without significant changes. These value classes are still nullable, lack a guaranteed layout, and can't be observed torn, unlike in C++/C#/Go.

pjmlp 1mo ago
Nullability is coming later, and already with Panama you have plenty of room to do C like stuff. Go isn't much better.
- tsimionescu 1mo ago
  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.
  - debugnik 1mo ago
    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.
- debugnik 1mo ago
  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.

pjmlp 1mo ago

Nullability is coming later, and already with Panama you have plenty of room to do C like stuff. Go isn't much better.

tsimionescu 1mo ago
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.
- debugnik 1mo ago
  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.
debugnik 1mo ago
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.