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

411–420 of 464 posts

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

#411

Post by kuhsaft »

DarkNova6 wrote: post #332
jaen wrote: post #132

Earlier quoted context omitted.

Could you actually explain/exemplify any of the gotchas and what's been made better (or is this just handwaving)?

I've been let down by structs in C# repeatedly. First of all, there are no constructor guarantees and you can never fully avoid them representing an illegal state. Which, wouldn't be so bad if there was some kind of post-construction validation, but this also isn't part of the language. This is fine if you hand-roll all your code yourself, but I often use mapping libraries to lower the code footprint and the problems…

I hate to say it. But thats user error. The struct paradigm is different from classes. Structs are meant to be plain-old data types; simply a typed span of memory.

Structs are values, classes are entities with encapsulation.

The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral.

Structs are useful when working with spans of memory.

Another example of a good usage of struct is Guid, which is 128 bits of data packed together.

The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime.

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

#412

Post by pron »

jayd16 wrote: post #409
pron wrote: post #396

Earlier quoted context omitted.

.NET do what they do because they believe many people like it, and we do what we do because we believe many people like it. Because different developers like different things, we may both be right. The only explanation to why we do what we do is that we believe it works well for us, and we know what everyone should know, which is that what we do can't be universally liked because developers have different preferences…

I like Java too but this is pure cope. By this logic Python's threading model is the best.

I think you misunderstood my point. I'm not claiming that the most successful products necessarily have all the best features. I am saying that the claim that "team X consistently makes worse decisions than team Y" is hard to support if team X is winning. At least some of their decisions are probably better, and those ones also probably matter more.

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

#413

Post by pron »

sroussey wrote: post #368
pron wrote: post #289

Earlier quoted context omitted.

I think user-mode threads are better when the language already has threads . I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.

https://github.com/oven-sh/WebKit/pull/249

I'd be very surprised if Google go for it.

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

#414

Post by jayd16 »

revetkn wrote: post #229
ptx wrote: post #219

Earlier quoted context omitted.

What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?

Regarding "What's wrong with what .NET did with threads?", see https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html (relevant part below): An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that asyn…

Regarding coloring...

You still can't block in UI code, right? You don't know whether you're on a virtual thread or the UI thread (even if its virtual) by design. You still have to bifurcate your APIs into blocking and non-blocking, don't you? Virtual threads will help you keeping the CPU fed but it won't handle separating UI and non-UI work, or know when a frame deadline ends.

Have there been Swing specific updates to deal with that?

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

#415

Post by DarkNova6 »

kuhsaft wrote: post #411
DarkNova6 wrote: post #332

Earlier quoted context omitted.

I've been let down by structs in C# repeatedly. First of all, there are no constructor guarantees and you can never fully avoid them representing an illegal state. Which, wouldn't be so bad if there was some kind of post-construction validation, but this also isn't part of the language. This is fine if you hand-roll all your code yourself, but I often use mapping libraries to lower the code footprint and the problems…

I hate to say it. But thats user error. The struct paradigm is different from classes. Structs are meant to be plain-old data types; simply a typed span of memory. Structs are values, classes are entities with encapsulation. The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral. Structs are useful when working with spans of memory. Another example of a good usage of…

This is what makes the nuances of Valhalla's Value types so compelling. The idea are granular structs with "Integrity by default", where you can selectively give up constraints on class design to get performance characteristics.

Structs in most languages simply bunch a couple constraints together to get another set of performance benefits, but there's no law stating that they couldn't be singled out. In the design of Valhalla, it states that types can come in 4 buckets:

1: Fully identity classes (total control, mutable)

2: Value Based classes (no mutability, but full integrity and dense memory layout)

3: Implicitly constructed values (forced empty default constructor for swift bulk array initialization)

4: Tearable Values (No cross-field integrity during runtime for parallel access)

And I bet that for a vast majority of developers, #4 will come to a shocking surprise, thinking "values are threat safe" because they are told to use immutables.

This way of splitting up structs is the real interesting part of Valhalla, but this shitty AI-generated article buries everything interesting.

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

#416

Post by jayd16 »

petilon wrote: post #334
zoogeny wrote: post #328

Earlier quoted context omitted.

I believe that the statement `a.x = 100;` is invalid since Record types are immutable. That is, the situation you are afraid of should be impossible.

If that's true then it is a significant improvement over structs in C#. But the distinction still matters. Value-vs-reference semantics affect equality, identity, nullability, arrays, collections, boxing, and performance. So this is not just an implementation detail. If a language hides that distinction at the use site, it increases the burden on the reader and makes code harder to reason about.

C# has Properties that make setters look like fields anyway. There's no ambiguity between value and object in C# because there is no promise that that syntax only sets a field. Love it or hate it, you just need to know what you're calling.

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

#417

Post by kuhsaft »

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 C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime, and they can be scalarized like C# structs.

Java ‘value class’ only flattens if the total size of the class data fits within an atomic read/write op. You can force it to flatten, but you may have tearing like C# struct.

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

#418

Post by kuhsaft »

DarkNova6 wrote: post #415
kuhsaft wrote: post #411

Earlier quoted context omitted.

I hate to say it. But thats user error. The struct paradigm is different from classes. Structs are meant to be plain-old data types; simply a typed span of memory. Structs are values, classes are entities with encapsulation. The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral. Structs are useful when working with spans of memory. Another example of a good usage of…

This is what makes the nuances of Valhalla's Value types so compelling. The idea are granular structs with "Integrity by default", where you can selectively give up constraints on class design to get performance characteristics. Structs in most languages simply bunch a couple constraints together to get another set of performance benefits, but there's no law stating that they couldn't be singled out. In the design of…

Imo #4 is why it’s not that useful. If the data is larger than an atomic read/write op the data isn’t flattened and it’s a regular object with value equality and immutability.

You have to opt into force flattening, and then it’s the same as a struct, except it’s still heap allocated without escape analysis. You still have to implement synchronization to prevent tearing.

Static code analysis can give you a warning for potential tearing of structs.

DotNext.Threading provides Atomic to enable high-performance atomic operations on structs without heap allocation.

https://dotnet.github.io/dotNext/features/core/atomic.html

The design of value classes just seems counteractive to its purpose: memory management. If I want to manage contiguous blocks of memory, let me manage contiguous blocks of memory. If I want to allocate something on the stack, let me allocate something on the stack.

The paradigms of struct vs object are too different and they’re trying to combine them into one.

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

#419

Post by legitronics »

andrepd wrote: post #330
rayiner wrote: post #275

Earlier quoted context omitted.

Oh my god did we inadvertently train AIs on idiotspeak.

No, we actually trained it on standardised tests https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...

Thank you for sharing this. It brought together things I had suspected but not from his perspective. Also pleasant to read something that used rhetorical devices in a cohesive way instead of just as sprinkled on flavor packets.

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

#420

Post by jayd16 »

rom1v wrote: post #58

> The difference in the code is exactly one word: value. What is unclear to me is why the decision to use a Point instance as a value or as a reference is made in the class definition rather than by the caller. > Point[] point = new Point[10]; For the same class, I might need an array of values in one place and an array of references elsewhere within the same codebase.

It would really break the GC or the type system if you did that. If you return a single point out of a 100k long array, it has to pin the array? How do you track the GC root? Struct array elements need back pointers?

Conversely, if it auto-copies now you have to contend with runtime state changing the pass semantics?

Post reply on HN