3 ms·

This is interesting. Java desperately needs an array of struct for type safe sugar over high performance arenas, but the areas you’d turn to this would be in a

This is interesting. Java desperately needs an array of struct for type safe sugar over high performance arenas, but the areas you’d turn to this would be in a zero allocation effort where the cost of the this library’s off-heap and the object allocation in the getters and setters etc largely negate the advantages for a lot of use cases.

joe_mwangi 5mo ago
Yup. Totally agree. Java does needs an array of structs. Hopefully value classes will help out through flattened array. But in future, one can use value records with this library with probable zero cost allocation. But the library doesn't use any reflection calls for get and set hence high performance as a result, and using records helps a lot with escape analysis. Planning to do some serious benchmarks soon. Some preliminary tests shows it's similar to c code (example code in test package). Performance suffers if record fields are arrays due to heap allocation of arrays.
- PaulHoule 5mo ago
  The thing I coded where I felt the weight of the GC the most was a chess engine in Java that needed transposition tables. Like using regular HashMap(s) or anything similar it was too slow to really speed up the engine. If my son had stayed interested in chess I would have coded up an off-heap transposition tables but he switched to guitar which changed my side projects.
  - joe_mwangi 5mo ago
    Hope you come back. Would be cool to venture in this new data oriented programming phase java has invested a lot in.
    - traderj0e 5mo ago
      I'm glad they saw the light. Last time I used Java was in high school when it was version 7, when it was pure OOP. Didn't even have lambdas. After I learned other languages, I didn't want to use Java again, seemed like a lot of boilerplate for something that didn't even give good performance.
      - PaulHoule 5mo ago
        I use Java all the time for ordinary programming at work, I think it is great, but I'm not in a hurry to mess with stuff off-heap.
      - dionian 5mo ago
        Java has always given good performance for most of my use cases. Like backend servers where startup time is mostly irrelevant.
      - saagarjha 5mo ago
        Maybe you should check again if the last time you used it was Java 7.
        traderj0e 5mo ago
        I've looked, it's better now, hence my comment that they saw the light. They got lambdas, records, and auto types. More importantly they got virtual threads, but that's unrelated.
  - cindyllm 5mo ago
    [dead]
- fweimer 5mo ago
  I doubt value classes will be helpful here because the array would have to be immutable. Context: https://openjdk.org/jeps/401 https://openjdk.org/jeps/401
  - joe_mwangi 5mo ago
    Yeaaah. You might be right. Hopefully we have this one day https://openjdk.org/jeps/8261007 https://openjdk.org/jeps/8261007
  - spockz 5mo ago
    Why does the array need to be immutable? Isn’t it enough to allocate the pessimistic max size of the record times the size of the array? In go slices work quite nicely to deal with “immutable” arrays and still be able to work on views on those arrays while keeping the same memory backing.
    - deleted 5mo ago
      [deleted]
    - kbolino 5mo ago
      There's two problems as I see it. The first is that value types themselves are immutable. This affects code generation and optimization. If you were to modify the value with unmanaged code then you may not observe the modification properly from managed code. Maybe this restriction will get relaxed, but I don't see that on any roadmap any time soon. The second problem is that value types are still nullable. The flattened array is not going to be identical to a Go slice or a C# Span etc. because it has to track the nullness of each element. It seems they don't want to nail down the exact storage format for that yet, possibly to change it in the future, and possibly because they want to add language-level control over nullability eventually too.
    - fweimer 5mo ago
      As kbolino said, value objects are immutable. If you can get a reference to a value object in an array, the array has to be immutable. If you cannot get a reference, it's possible to maintain mutability, but all access would involve copies. But it's not clear that this is what most people want because it's rather similar to what you can do with library-based solutions today (involving ByteBuffers and whatnot).
zmmmmm 5mo ago
I find it weird that the people steering Java have been seemingly willing to sit out the use case high performance computation while it has so dominated the computing landscape. They are just patiently incrementally iterating on all these JEP's that would support dramatically improved capabilities and make Java a very attractive platform for ML - but they keep fretting over minor interface adjustments, cycle after cycle. I get there is a philosophy of keeping the language stable and well designed, but this is really taking it to an extreme in the face of missing an entire segment of computing.
- joe_mwangi 5mo ago
  It's a long roadmap, but this is their ultimate objective. Once java has value classes, future carrier classes and member patterns, that's when we shall see some very huge interest for java in ML. Also, they plan to introduce typeclasses in which it will be convenient to introduce operator overloading, and collection/array literals etc syntax. The idea is to unify the types in java, and then enable much stronger semantics to ensure data oriented programming becomes ergonomic in java.
  - whizzter 5mo ago
    Valuetypes has been on the roadmap forever, meanwhile they put in the effort and bought out greenthreads out of retirement as virtual threads. Even if they started properly on valuetypes today, it's probably still a 10 year slog to get the ecosystem to follow.
    - elric 5mo ago
      Value types are a work in progress. It won't be (another) 10 years. Give it a few more releases.
      - joe_mwangi 5mo ago
        Yup. They started transferring to the main line, but will require many tests to know if they have any issues. https://github.com/openjdk/jdk/pull/31120 https://github.com/openjdk/jdk/pull/31120

joe_mwangi 5mo ago

Yup. Totally agree. Java does needs an array of structs. Hopefully value classes will help out through flattened array. But in future, one can use value records with this library with probable zero cost allocation. But the library doesn't use any reflection calls for get and set hence high performance as a result, and using records helps a lot with escape analysis. Planning to do some serious benchmarks soon. Some preliminary tests shows it's similar to c code (example code in test package). Performance suffers if record fields are arrays due to heap allocation of arrays.

PaulHoule 5mo ago
The thing I coded where I felt the weight of the GC the most was a chess engine in Java that needed transposition tables. Like using regular HashMap(s) or anything similar it was too slow to really speed up the engine. If my son had stayed interested in chess I would have coded up an off-heap transposition tables but he switched to guitar which changed my side projects.
- joe_mwangi 5mo ago
  Hope you come back. Would be cool to venture in this new data oriented programming phase java has invested a lot in.
  - traderj0e 5mo ago
    I'm glad they saw the light. Last time I used Java was in high school when it was version 7, when it was pure OOP. Didn't even have lambdas. After I learned other languages, I didn't want to use Java again, seemed like a lot of boilerplate for something that didn't even give good performance.
    - PaulHoule 5mo ago
      I use Java all the time for ordinary programming at work, I think it is great, but I'm not in a hurry to mess with stuff off-heap.
    - dionian 5mo ago
      Java has always given good performance for most of my use cases. Like backend servers where startup time is mostly irrelevant.
    - saagarjha 5mo ago
      Maybe you should check again if the last time you used it was Java 7.
      - traderj0e 5mo ago
        I've looked, it's better now, hence my comment that they saw the light. They got lambdas, records, and auto types. More importantly they got virtual threads, but that's unrelated.
- cindyllm 5mo ago
  [dead]
fweimer 5mo ago
I doubt value classes will be helpful here because the array would have to be immutable. Context: https://openjdk.org/jeps/401 https://openjdk.org/jeps/401
- joe_mwangi 5mo ago
  Yeaaah. You might be right. Hopefully we have this one day https://openjdk.org/jeps/8261007 https://openjdk.org/jeps/8261007
- spockz 5mo ago
  Why does the array need to be immutable? Isn’t it enough to allocate the pessimistic max size of the record times the size of the array? In go slices work quite nicely to deal with “immutable” arrays and still be able to work on views on those arrays while keeping the same memory backing.
  - deleted 5mo ago
    [deleted]
  - kbolino 5mo ago
    There's two problems as I see it. The first is that value types themselves are immutable. This affects code generation and optimization. If you were to modify the value with unmanaged code then you may not observe the modification properly from managed code. Maybe this restriction will get relaxed, but I don't see that on any roadmap any time soon. The second problem is that value types are still nullable. The flattened array is not going to be identical to a Go slice or a C# Span etc. because it has to track the nullness of each element. It seems they don't want to nail down the exact storage format for that yet, possibly to change it in the future, and possibly because they want to add language-level control over nullability eventually too.
  - fweimer 5mo ago
    As kbolino said, value objects are immutable. If you can get a reference to a value object in an array, the array has to be immutable. If you cannot get a reference, it's possible to maintain mutability, but all access would involve copies. But it's not clear that this is what most people want because it's rather similar to what you can do with library-based solutions today (involving ByteBuffers and whatnot).

zmmmmm 5mo ago

I find it weird that the people steering Java have been seemingly willing to sit out the use case high performance computation while it has so dominated the computing landscape. They are just patiently incrementally iterating on all these JEP's that would support dramatically improved capabilities and make Java a very attractive platform for ML - but they keep fretting over minor interface adjustments, cycle after cycle. I get there is a philosophy of keeping the language stable and well designed, but this is really taking it to an extreme in the face of missing an entire segment of computing.

joe_mwangi 5mo ago
It's a long roadmap, but this is their ultimate objective. Once java has value classes, future carrier classes and member patterns, that's when we shall see some very huge interest for java in ML. Also, they plan to introduce typeclasses in which it will be convenient to introduce operator overloading, and collection/array literals etc syntax. The idea is to unify the types in java, and then enable much stronger semantics to ensure data oriented programming becomes ergonomic in java.
- whizzter 5mo ago
  Valuetypes has been on the roadmap forever, meanwhile they put in the effort and bought out greenthreads out of retirement as virtual threads. Even if they started properly on valuetypes today, it's probably still a 10 year slog to get the ecosystem to follow.
  - elric 5mo ago
    Value types are a work in progress. It won't be (another) 10 years. Give it a few more releases.
    - joe_mwangi 5mo ago
      Yup. They started transferring to the main line, but will require many tests to know if they have any issues. https://github.com/openjdk/jdk/pull/31120 https://github.com/openjdk/jdk/pull/31120