Live data from Hacker News

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

jvm-weekly.com

191–200 of 464 posts

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#191
> There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent access).

I really hope they give an escape hatch for this. It will make it really hard to extract a lot of the benefit of valhala if you can't make a thread unsafe value class. It's also one of those problems that will be quite hard to run into. You basically need something like this

    class Bar {
      static Foo value[] = new Foo[10];
      static void setFooFromManyThreads(Foo foo) {
        value[0] = foo;
      }
      
      value record Foo(int x, int y, int z) {};
    }
Not something you typically run into and generally already a thread safety problem.

The solution is also simple, a `synchronized{}` block will fix it if you need to have a tearable class that's written from multiple threads.

But the other thing is that for SIMD operations, you really need flattening, and that really does typically mean having something like `Foo(double x, double y, double z)` in play. It'd be a shame if the way we have to do this is a struct of arrays.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#192

I just got my projects up to JDK 21 a few months ago. Working on trying to get one upgraded to JDK 25 now and now they're talking about delivering JDK 28 in less than a year from now. How are you supposed to keep up with these rapid updates?

What did you go from to get to 21?

Mostly just hit the LTSes is what we've been doing and since about 17 it's been a pretty easy process in general.

Protip: If you ditch lombok everything gets a lot easier.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#193
post #17

Earlier quoted context omitted.

> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentr…

> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

Agreed. I jumped on the .NET bandwagon in 2000 and was on it for several years but ended up going back to Java by 2005.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#194
post #126

Earlier quoted context omitted.

Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.

I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability. As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best te…

In case you want to edit it back in: in the 3rd paragraph second sentence, the star in your int* got gobble up by formatting to italics.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#195
post #108

Earlier quoted context omitted.

I wanted to comment on this as well. The article mentions it but if you've never used Java in anger (is there any other way?) then readers may not understand the true implications of this because it's a breaking change, something Java rarely does. I'll explain for the non-Java people. Java separates checking identity and equality for objects. == basically checks if two pointers are the same. Equality is a subjective…

new Integer(10) == new Integer(10) // true Before value classes this would always be false. The only time comparing Integer objects with == could be true is if Integer object was create by going through Integer.valueOf (or obviously if they were the same object reference.) By default the cached values where -127 to 127, but that is tuneable at runtime. https://github.com/openjdk/jdk/blob/jdk-27%2B27/src/java.bas...

So you've made my point in showing how complex this is because you're incorrect [1][2]:

> By default, Java maintains a cache of Integer objects for values between -128 and +127.

[1]: https://stackoverflow.com/questions/3130311/weird-integer-bo...

[2]: https://dev.to/marzuk16/understanding-integer-caching-in-jav...

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#196

> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap. How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit repre…

> No headers per element. No pointers. No jumping around the heap.

that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it.

[1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#197
I found a solution for what seems to be the same problem, in a different language: a particular type of lists, where the class metadata is stored once and the data for each instance is contiguously stored in a flat array.

Not sure if it covers exactly the same terrain, but perusing the article, it seems to be the case, with a single instance being the degenerate case.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#199
post #17

Earlier quoted context omitted.

> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully…

> .NET is about extending an existing application (Servlet API vs IIS)

I don't think this is true anymore since ASP.NET Core. While you can still run under IIS but it's a more typical reverse proxy setup instead of running inside IIS.

> You can't wrap streams in .NET

You've always been able to wrap streams in .NET so I'm not sure what you mean by this

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#200
post #154

Earlier quoted context omitted.

That's not quite how it works in Valhalla. Because Integer and int already exists, your declarations above will be interpreted with those meanings, but (assuming some TBD nullability annotation), they will be equivalent to `int? x` and `Integer! x` respectively. In other words, the nullability of a variable is a separate concern from the data type, and other than the different defaults on variable declarations (as th…

This may be true, hopefully, in a future version of Java, if the article isn't wrong. In JDK 28 with the Preview feature enabled, int is not nullable and Integer is nullable, and they are thus different types under the hood. Which also means that on most CPU architectures, Long[] will be just as inefficient compared to long[] as it was in any previous version of Java.

> int is not nullable and Integer is nullable, and they are thus different types under the hood

Yes and no, because in Java we have runtime types and compile-time types. The frontend compiler will treat these types as having different defaults on nullability, but they'll compile down to the same representation (when appropriate). I.e. if the compiler sees that some Integer variable is never null, it will compile down to the same thing it would if it were declared an int.

You're right, however, that on the heap, until the language adds nullability information, the compiler cannot generally know that an Integer will never be null (unless it's a final field), so it's likely that, unlike on the stack, you'll get a different representation.

Post reply on HN