5 ms·

Are they going to introduce zero-cost structs? Kinda like Rust guarantees that Option<T> has the same size as T (aka free like in free beer).

vips7L 5y ago
Primitive classes are being worked on in Project Valhalla.
- geophile 5y ago
  I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to do. This is such an important thing to add to Java, and it seems to be perpetually off the stove, not even on the back burner.
  - hyperpape 5y ago
    I haven't been following it incredibly closely, but I have checked in from time to time. It's a hard problem, but there's a lot of real progress (https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md https://github.com/openjdk/valhalla-docs/blob/main/site/desi...). I'd wager that it will ship by the next LTS, in 2024.
    - vips7L 5y ago
      2023 (hopefully)! They're proposing moving LTS to 2 years instead of 3.
  - zokier 5y ago
    > This is such an important thing to add to Java, and it seems to be perpetually off the stove, not even on the back burner. Valhalla is being actively worked on, I'm not sure what you are implying here.
  - pjmlp 5y ago
    Because they don't want to do a Python move, and those compiled JARs from 2000 should keep working as much as possible on a Valhala aware JVM.
  - vips7L 5y ago
    Some features take a long time when you have millions of users and billions of loc. Goetz recently did a State of Valhalla interview here: https://www.youtube.com/watch?v=x1_DBqJrykM https://www.youtube.com/watch?v=x1_DBqJrykM
  - stickfigure 5y ago
    Alternatively: This is such a (potentially) big change, it's important to get right. I'd be disappointed if an inadequately-baked solution gets rushed in. Another way of looking at it: This is fundamentally just a performance optimization. Java performance is already exceptional for most of Java's popular use cases (business processing). While valuable, I don't think this one feature is quite as important as you consider it.
    - deepsun 5y ago
      That makes sense, given the fact that they made "new Foo()" pretty lightweight anyway (for CPU, not for RAM).
  - nlitened 5y ago
    > If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to do. As an aside, and not to say that Valhalla is not needed (I am looking forward to it very much, along with Loom), I’ve recently learned that for many use cases (not all) when you want gigabytes of struct arrays, a bunch of equal-sized primitive arrays, one per struct field, might work even better from memory requirement and cache locality perspective.
    - samus 5y ago
      The semantics of primitive types should make it possible for the JVM to apply this optimization automatically. Maybe controlled via an annotation. But no clue whether it's on the roadmap.
  - native_samples 5y ago
    It's mostly implemented in a branch. You can download a version of Java that can do this today. There's more work to do before it can be merged though, and will probably ship in incremental pieces.
zokier 5y ago
> Kinda like Rust guarantees that Option<T> has the same size as T (aka free like in free beer). That is not correct. Trivial counterexample: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=941b8b2833b2537af9c2eac82d89980e https://play.rust-lang.org/?version=stable&mode=debug&editio... prints 4 8 i.e. Option<T> is 4 bytes larger than plain T
- deepsun 5y ago
 Sure, I meant: Rust guarantees to optimize the following types T such that Option<T> has the same size as T: Box &U &mut U fn, extern "C" fn num::NonZero* ptr::NonNull #[repr(transparent)] struct around one of the types in this list. UPDATE: Or, better per your example: struct T {i: i32} takes the same size as i32: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b95205ebeff6ddbe08a0b9d9900bb260 https://play.rust-lang.org/?version=stable&mode=debug&editio...
CodeIsTheEnd 5y ago
A clarification: Rust only makes this guarantee for certain types[1] which you would expect to be represented by a simple pointer under the hood (e.g., Box, &T, function pointers) and for other types which can never be all 0. Making this optimization for something like Option<u8> is, naturally, impossible. (I assume you are aware of this and were implicitly referring to this optimization.) [1]: https://doc.rust-lang.org/std/option/#representation https://doc.rust-lang.org/std/option/#representation
throwaway4good 5y ago
You get null for free.
- mleo 5y ago
 Can’t tell if this meant to be a statement of fact, opinion or sarcasm. Over the course of 20 years have I have probably spent days of time tracking down NPEs in code being developed and after the fact in production releases. The amount of extra code and time spent to determine if variable is null certainly isn’t free. Optional at least states the variable may not be referencing anything and provides helpful methods to chain mapping and conditionals to more easily deal with null values.
 - dtech 5y ago
 I really like the Kotlin approach, where they just embraced null being a fact of life on the JVM/JS and instead integrated nullability into the type-system [1]. C# and Typescript do something similar. So then you get the best of both world, the safety of Optional without the boxing overhead. [1] https://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html
 - bdamm 5y ago
 This really sounds like the way to go, although of course it is too late for Java. Optional feels awkward, and there's no more safety than we already have since the JVM null-checks anyway. if( arg.isPresent() ) ... vs if( arg != null ) ... How is this better?
 - rovolo 5y ago
 The main advantage is that Optional is inconvenient and forces you to consider the null case. It's easy to forget that values can be null and assume they're not, e.g. auto-unboxing Long getSomeValue(); int max = Math.max(0, obj.getSomeValue()); The Optional value forces you to type some text basically acknowledging that the value can be null. Optional<Long> getSomeValue(); ... obj.getSomeValue().get()); I'm not saying Optional is a great solution. It's essentially a notification that a value is nullable.
tathisit 5y ago
It's impossible for Option<T> to be the same size as T. Option is a tagged enum, where will the tag go?
- agolliver 5y ago
 Looks like it's only true for pointer types which cannot be null (so they can reuse null as the None tag) https://doc.rust-lang.org/std/option/ https://doc.rust-lang.org/std/option/

vips7L 5y ago

Primitive classes are being worked on in Project Valhalla.

geophile 5y ago
I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to do. This is such an important thing to add to Java, and it seems to be perpetually off the stove, not even on the back burner.
- hyperpape 5y ago
  I haven't been following it incredibly closely, but I have checked in from time to time. It's a hard problem, but there's a lot of real progress (https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md https://github.com/openjdk/valhalla-docs/blob/main/site/desi...). I'd wager that it will ship by the next LTS, in 2024.
  - vips7L 5y ago
    2023 (hopefully)! They're proposing moving LTS to 2 years instead of 3.
- zokier 5y ago
  > This is such an important thing to add to Java, and it seems to be perpetually off the stove, not even on the back burner. Valhalla is being actively worked on, I'm not sure what you are implying here.
- pjmlp 5y ago
  Because they don't want to do a Python move, and those compiled JARs from 2000 should keep working as much as possible on a Valhala aware JVM.
- vips7L 5y ago
  Some features take a long time when you have millions of users and billions of loc. Goetz recently did a State of Valhalla interview here: https://www.youtube.com/watch?v=x1_DBqJrykM https://www.youtube.com/watch?v=x1_DBqJrykM
- stickfigure 5y ago
  Alternatively: This is such a (potentially) big change, it's important to get right. I'd be disappointed if an inadequately-baked solution gets rushed in. Another way of looking at it: This is fundamentally just a performance optimization. Java performance is already exceptional for most of Java's popular use cases (business processing). While valuable, I don't think this one feature is quite as important as you consider it.
  - deepsun 5y ago
    That makes sense, given the fact that they made "new Foo()" pretty lightweight anyway (for CPU, not for RAM).
- nlitened 5y ago
  > If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to do. As an aside, and not to say that Valhalla is not needed (I am looking forward to it very much, along with Loom), I’ve recently learned that for many use cases (not all) when you want gigabytes of struct arrays, a bunch of equal-sized primitive arrays, one per struct field, might work even better from memory requirement and cache locality perspective.
  - samus 5y ago
    The semantics of primitive types should make it possible for the JVM to apply this optimization automatically. Maybe controlled via an annotation. But no clue whether it's on the roadmap.
- native_samples 5y ago
  It's mostly implemented in a branch. You can download a version of Java that can do this today. There's more work to do before it can be merged though, and will probably ship in incremental pieces.

zokier 5y ago

> Kinda like Rust guarantees that Option<T> has the same size as T (aka free like in free beer). That is not correct. Trivial counterexample: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=941b8b2833b2537af9c2eac82d89980e https://play.rust-lang.org/?version=stable&mode=debug&editio... prints 4 8 i.e. Option<T> is 4 bytes larger than plain T

deepsun 5y ago
Sure, I meant: Rust guarantees to optimize the following types T such that Option<T> has the same size as T: Box &U &mut U fn, extern "C" fn num::NonZero* ptr::NonNull #[repr(transparent)] struct around one of the types in this list. UPDATE: Or, better per your example: struct T {i: i32} takes the same size as i32: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b95205ebeff6ddbe08a0b9d9900bb260 https://play.rust-lang.org/?version=stable&mode=debug&editio...

CodeIsTheEnd 5y ago

A clarification: Rust only makes this guarantee for certain types[1] which you would expect to be represented by a simple pointer under the hood (e.g., Box, &T, function pointers) and for other types which can never be all 0. Making this optimization for something like Option<u8> is, naturally, impossible. (I assume you are aware of this and were implicitly referring to this optimization.) [1]: https://doc.rust-lang.org/std/option/#representation https://doc.rust-lang.org/std/option/#representation

throwaway4good 5y ago

You get null for free.

mleo 5y ago
Can’t tell if this meant to be a statement of fact, opinion or sarcasm. Over the course of 20 years have I have probably spent days of time tracking down NPEs in code being developed and after the fact in production releases. The amount of extra code and time spent to determine if variable is null certainly isn’t free. Optional at least states the variable may not be referencing anything and provides helpful methods to chain mapping and conditionals to more easily deal with null values.
- dtech 5y ago
 I really like the Kotlin approach, where they just embraced null being a fact of life on the JVM/JS and instead integrated nullability into the type-system [1]. C# and Typescript do something similar. So then you get the best of both world, the safety of Optional without the boxing overhead. [1] https://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html
 - bdamm 5y ago
 This really sounds like the way to go, although of course it is too late for Java. Optional feels awkward, and there's no more safety than we already have since the JVM null-checks anyway. if( arg.isPresent() ) ... vs if( arg != null ) ... How is this better?
 - rovolo 5y ago
 The main advantage is that Optional is inconvenient and forces you to consider the null case. It's easy to forget that values can be null and assume they're not, e.g. auto-unboxing Long getSomeValue(); int max = Math.max(0, obj.getSomeValue()); The Optional value forces you to type some text basically acknowledging that the value can be null. Optional<Long> getSomeValue(); ... obj.getSomeValue().get()); I'm not saying Optional is a great solution. It's essentially a notification that a value is nullable.

tathisit 5y ago

It's impossible for Option<T> to be the same size as T. Option is a tagged enum, where will the tag go?

agolliver 5y ago
Looks like it's only true for pointer types which cannot be null (so they can reuse null as the None tag) https://doc.rust-lang.org/std/option/ https://doc.rust-lang.org/std/option/