Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jvm-weekly.com

Post reply on HN
Print view View original

21–30 of 464 posts

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

#21

Post by layer8 »

_old_dude_ wrote: post #10
torginus wrote: post #5

I know its a faux pas in the Java world to acknowledge the existence of .NET, but how does this differ from .NET structs? Value types, generic specialization, boxing - a quick skim makes it looks like they picked the same choices.

The article has a section about that. For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value. I do not think you can do stack allocation in Java.

I don’t see a difference between pass by copy and pass by value.

The mutability difference is that part of a struct can be modified in place, which value classes can’t: the value of a complete value-class variable (or array slot) can only be modified (reassigned) as a whole. This is presumably because object references to value-class objects can be created, and those objects should be immutable so their identity doesn’t matter.

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

#22

Post by sysguest »

gf000 wrote: post #16
torginus wrote: post #8

Earlier quoted context omitted.

I don't wanna badmouth Java people, but how they push the idea that this thing is some sort of genuine breakthrough that took multiple PhDs years of cutting-edge research to implement, when in fact they basically copied what .NET did from basically year 1, is not a good look. Again, not trying to turn this into a .NET vs Java thing, I'd have been much happier if they reached some new and interesting conclusions.

> genuine breakthrough Well, it is - because they had to make it with almost perfect backwards compatibility for one of the most popular languages with trillions of lines of code produced over decades. Sure, adding it to a new language is not hard. Adding it to Java which has primitives, generics and boxing, finding ways that seamlessly cover the differences between objects and primitives, while trying to plan for th…

idk maybe java should adopt something similar to rust's "edition"?

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

#23

Post by gf000 »

andyjohnson0 wrote: post #12
rf15 wrote: post #4

I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly. > The team, faithful to the lesson “simplify…

> 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…

> The stewardship of Java seems rather lacking

In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times from heap size. Like if anything, Java is at the best place it has ever been.

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

#24

Post by ahartmetz »

layer8 wrote: post #15

> But careful: == looks at internal state, which isn’t always what the object represents, so for “is this the same data” comparisons keep using equals. So == for value classes will basically be like memcmp() . That is a bit unfortunate, as it breaks encapsulation, exposing implementation details. Client code can use this to do case distinctions based on how a given value is internally represented. In a way, it’s wors…

If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero.

It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.

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

#25

Post by rf15 »

geokon wrote: post #13

a few questions for the pros > "The defining trait: no identity" I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective > There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent ac…

> I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective

It feels like an orthogonal objective and honestly arbitrary distinction, yes.

> Isn't this a race condition and "undefined bahvior"..? Having to limit yourself to atomic sizes seems like a huge limitation, to accomodate what is most likely buggy code.

I think they meant it like the appearance of atomic behavior from a java multithreading view.

> Does this happen in actuality?

Yes, it does happen. Having guarantees on this front leads to better performance.

> But when writing Clojure apps the JVM always reserves absurd amounts of heapspace on my machine (to my annoyance)

Might be a configuration problem?

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

#26

Post by rf15 »

rzmmm wrote: post #20
rf15 wrote: post #4

I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly. > The team, faithful to the lesson “simplify…

This is mainly for performance and memory layouts, it would not have improved safety guarantees of java.

It would have implicitly brought some null-safety to java with primitive-like classes that can not be null.

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

#27

Post by lmm »

gf000 wrote: post #23
andyjohnson0 wrote: post #12

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…

> The stewardship of Java seems rather lacking In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times f…

> They have added proper algebraic data types to the language

No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.

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

#28

Post by _old_dude_ »

layer8 wrote: post #21
_old_dude_ wrote: post #10

Earlier quoted context omitted.

The article has a section about that. For me, a struct in C/C# can be modified and is passed by copy while a value class can not be modified and is passed by value. I do not think you can do stack allocation in Java.

I don’t see a difference between pass by copy and pass by value. The mutability difference is that part of a struct can be modified in place, which value classes can’t: the value of a complete value-class variable (or array slot) can only be modified (reassigned) as a whole. This is presumably because object references to value-class objects can be created, and those objects should be immutable so their identity does…

I think pass by copy is a consequence of being modifiable.

The other solution is to stack allocate and pass a pointer but as i said, unlike in C#, i do not think it's possible to do that in Java.

In Go, you can stack allocate but when you send a pointer (that escapes), the compiler will heap allocate the object.

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

#29

Post by gf000 »

geokon wrote: post #13

a few questions for the pros > "The defining trait: no identity" I get that this makes objects behave like primitive types. Maybe thats reason enough. But is it necessary for the performance boost and de-fluffing the objects? Seems like an orthogonal objective > There’s a catch worth knowing about here, though: flattened data has to be readable and writable atomically (otherwise it risks “tearing” under concurrent ac…

> Is all the effort only gunna help lil toy ColorRGB examples

Arguably flattening mostly makes sense for these only.

And yeah, you are right that allocations happen on something called a thread local allocation buffer, which is basically just a pointer bump in cost and objects allocated one after the other should be physically close in memory for the most part (though an object's creation may require a bunch of other object's creation that would sit in-between). But these have headers, so not as dense as they could be (though due to GCs being generational, they may end up actually closer in the next gen? The in-between temporary objects wouldn't survive for the most part)

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

#30

Post by layer8 »

ahartmetz wrote: post #24
layer8 wrote: post #15

> But careful: == looks at internal state, which isn’t always what the object represents, so for “is this the same data” comparisons keep using equals. So == for value classes will basically be like memcmp() . That is a bit unfortunate, as it breaks encapsulation, exposing implementation details. Client code can use this to do case distinctions based on how a given value is internally represented. In a way, it’s wors…

If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero. It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.

There’s nothing wrong with having non-normalized representations, that’s why there is equals().

For example, you might have a value class for representing (limited-precision) fractions using two longs internally, for the numerator and denominator. For efficiency trade-off reasons, you don’t want to always shorten the fraction. But now client code can distinguish 2/3 from 4/6 using ==.

Scenarios of that sort are conceivable where this actually leaks sensitive information. In any case, it creates dependencies on implementation details where you don’t want to have them.

When designing a value class, you are now in the dilemma of either always having to normalize the representation, costing performance, or having your class be a funnel for leaking implementation details.

Post reply on HN