3 ms·

As I understand it, this is anyway an extremely limited perf enhancement - for any class whose data size isn't guaranteed to be atomically writable on your CPU,

As I understand it, this is anyway an extremely limited perf enhancement - for any class whose data size isn't guaranteed to be atomically writable on your CPU, after including the nullability overhead, it doesn't do anything, basically. On a CPU where 64 bits is the max guaranteed atomic read/write, even Point[] will not get optimized, since you need at least 65 bits of memory for a point value (since it has two 32 bit int fields, and it needs an extra bit to specify if it's null or not - so in practice it will take up 72 bits at the very least, possibly more with alignment requirements). But even after fixing this, if you have 3D points or if you need 64bit coordinates, your value type 3DPoints will still be individually heap allocated and your 3DPoint[] will store pointers to them, just like today, on most processors. Given that the JVM could already do escape analysis and allocate regular classes on the stack in certain scenarios, it's very unclear what benefit, if any, this will bring for normal processors for anything except the base wrapper types - even after implementing generic support and nullability for value types in a future JVM.

lowbloodsugar 4mo ago
Which is why this is the wrong approach. Again. This is a major misstep.
- boroboro4 4mo ago
  The core insight there is to separate value semantics (no identity) from reference (itself) semantics (nullability). While this particular change can bring very limited amount of improvements it’s still does some - probably smaller to no object header + more guaranteed optimizations for variables on stack. It’s when they land next part (nullability) it will shine fully - particularly on the intersection of not null and value. Alternatively if they introduce tearable semantics it will also shine - it would be possible to still optimize array of value classes, even if they are nullable (for example by having correspondent nullability mask). So they are taking right step in a right direction. They are just trying to land this incrementally.
  - lowbloodsugar 4mo ago
    It seems to me that the "and a null flag" is adding a tremendous amount of unneeded complexity. Supporting null seems to be about avoiding C#'s ref/in/out solution. I suppose that, from a JDK dev's perspective, that's a reasonable requirement. I just hope that we actually get non-null. I'm not sure the no-tearing rule is particular helpful either. Like, this is something folks get wrong all the time in regular java. There's plenty of places where we use unsynchronized classes and expect synchronization to occur in the containing class or other explicit lock. If atomic operations are a requirement, and non-atomic value types get turned into references, then value types seem pointless. I fear we're getting something called "Value types" with none of the actual benefits of value types. Like "we heard you want something called value types so here you are". No, we wanted a way to declare arrays of structured values without having to deref pointers, or to store structures inline as a field within an object. What I've read seems to be not that unless the structure's total size is 63 bits...
deleted 4mo ago
[deleted]

lowbloodsugar 4mo ago

Which is why this is the wrong approach. Again. This is a major misstep.

boroboro4 4mo ago
The core insight there is to separate value semantics (no identity) from reference (itself) semantics (nullability). While this particular change can bring very limited amount of improvements it’s still does some - probably smaller to no object header + more guaranteed optimizations for variables on stack. It’s when they land next part (nullability) it will shine fully - particularly on the intersection of not null and value. Alternatively if they introduce tearable semantics it will also shine - it would be possible to still optimize array of value classes, even if they are nullable (for example by having correspondent nullability mask). So they are taking right step in a right direction. They are just trying to land this incrementally.
- lowbloodsugar 4mo ago
  It seems to me that the "and a null flag" is adding a tremendous amount of unneeded complexity. Supporting null seems to be about avoiding C#'s ref/in/out solution. I suppose that, from a JDK dev's perspective, that's a reasonable requirement. I just hope that we actually get non-null. I'm not sure the no-tearing rule is particular helpful either. Like, this is something folks get wrong all the time in regular java. There's plenty of places where we use unsynchronized classes and expect synchronization to occur in the containing class or other explicit lock. If atomic operations are a requirement, and non-atomic value types get turned into references, then value types seem pointless. I fear we're getting something called "Value types" with none of the actual benefits of value types. Like "we heard you want something called value types so here you are". No, we wanted a way to declare arrays of structured values without having to deref pointers, or to store structures inline as a field within an object. What I've read seems to be not that unless the structure's total size is 63 bits...

deleted 4mo ago

[deleted]