Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28 • Hacker News Board

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

#431

Post by WorldMaker » Sat, Jun 20, 2026, 8:05 PM UTC

pjmlp wrote: post #428

WorldMaker wrote: post #427

Earlier quoted context omitted.

The DLR is just a shared library. It never changed anything about the CLR under the hood nor did it change anything about how Generics worked in the CLR (being the most relevant part of the thread here). IronPython could instantiate Generics just fine, and did just fine working with them. The DLR is not "abandoned" so much as "complete". Everything did survive the transition into modern .NET and IronPython 3.4.2 runs…

The addition of dynamic, and JIT being aware of IDynamicMetaObjectProvider also mattered. Even though most of the communication around dynamic was about COM support and Excel.

IDynamicMetaObjectProvider mostly just caches and returns System.Linq.Expressions for various asks, so again most of the JIT awareness is still just System.Linq.Expressions awareness.

The COM support is by implementing IDynamicMetaObjectProvider in a cross-language reusable base class.

The C# `dynamic` keyword adds some smarts about IDynamicMetaObjectProvider to the C# compiler, but those smarts were never seen to be needed as a low level tool in the CLR itself. And again, once the C# compiles the IDynamicMetaObjectProvider calls, those mostly just result in System.Linq.Expressions for the JIT compiler to optimize in the same way it optimizes other usages of Linq.

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

#432

Post by slavapestov » Sat, Jun 20, 2026, 8:17 PM UTC

w10-1 wrote: post #271

A bit fuzzy and dramatic; luckily the original documents are quite readable: top-level page: https://openjdk.org/projects/jdk/28/spec/ JEP status: https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=... I'd really like to see someone trace related developments in C#, Swift, Java, and Rust, since they all have been racing to catch up to hardware, and I believe they are cross-pollinating. (My concern is how all…

FWIW both Swift and Rust have had value types and generics that abstract over unboxed values since the start.

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

#433

Post by pregnenolone » Sat, Jun 20, 2026, 9:25 PM UTC

ozim wrote: post #314

pregnenolone wrote: post #310

Earlier quoted context omitted.

> It was always .NET No, it was not. What's called .NET now used to be .NET Core. And then there's .NET Framework which was commonly known as .NET. > "cannot be tweaked at all" Are you serious? Not only does the JDK have multiple GCs for different use cases (Serial, Parallel, G1, ZGC, Shenandoah), they have very refined tuning settings ( https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main#Main... / https://docs.o…

You just confirmed your ignorance about anything .NET related. Coming from someone claiming: "language wars" are silly and pointless. You are just so much in language wars I am just definitely ending the conversation.

I keep telling you what's what and you do nothing but gaslight me by trying to turn my words on me.

Language wars are silly and pointless. Someone tells me he/she uses language xyz, I basically don't care, do whatever works for you ,but God forbid you cross a .NET proponent. In case you haven't noticed, this is a post about Java. You mention Java, and the first thing that happens is a bunch of .NET maniacs popping up out of nowhere, telling you how Java copied this feature or how C# had that feature for years. What is this?

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

#434

Post by hyperpallium2 » Sat, Jun 20, 2026, 9:48 PM UTC

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 non-nullability issue seems to be about performance, not cognitive load (search the article for "writes atomically"), though not articulated.

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

#435

Post by hyperpallium2 » Sat, Jun 20, 2026, 9:52 PM UTC

This beaurcratic development feels like turning a super-tanker that's connected to a hundred other super-tankers. While I accept the priority of back-compatibility, I personally lack the working memory to manage it, while creative problem-solving.

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

#436

Post by cogman10 » Sat, Jun 20, 2026, 10:38 PM UTC

pjmlp wrote: post #429

cogman10 wrote: post #424

Earlier quoted context omitted.

> many still think nested anonymous classes are used. Anonymous classes are still used (sometimes). It simply depends on the circumstance of the lambda. For example, this will result in a new anonymous class being generated. void foo(String s) { stream.filter(i->s.equals(i)); } The class gets generated to capture the `s` variable. Indy gets used in the `filter` method because the incoming lambda or method reference c…

I had another idea given Brian's talk on the matter. Never bothered to actually look into the generated bytecodes.

Surprisingly hard to find good docs on this. [1]

I was wrong, it looks like the case I gave is one which doesn't result in a new anonymous class being generated. Instead the lambda metafactory gets involved to avoid that allocation.

I apparently didn't see what I thought I saw. I thought that I had seen new `lambda.$1` classes being created in call stacks when debugging. Maybe I did, but the lambda was serializable (we have that in some unfortunate places in our code base).

There are still cases where new classes get generated, but that's pretty much just for serialization.

[1] https://cr.openjdk.org/~briangoetz/lambda/lambda-translation...

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

#437

Post by capr » Sat, Jun 20, 2026, 11:51 PM UTC

That smells a lot like Facebook making a php compiler

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

#438

Post by cogman10 » Sun, Jun 21, 2026, 12:22 AM UTC

geokon wrote: post #351

cogman10 wrote: post #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 nee…

I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway? And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)

The problem is concurrent access. A write bit on the value doesn't really help as you have to check and update the bit using atomic instructions. But you'd also need to reserve that bit for every read as concurrent access wouldn't be safe.

That's the tearing problem.

It gets worse because things you can't generally do in the JVM can happen. For example, if your value class contains a reference to an object but that reference just so happens to split a tear, it's possible one thread to see an invalid reference while another thread is writing that object. That could be fixed with some added padding based on the architecture to make sure stored references aren't tearable.

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

#439

Post by tzs » Sun, Jun 21, 2026, 12:52 AM UTC

rezonant wrote: post #362

Raphael_Amiard wrote: post #268

Earlier quoted context omitted.

I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask: « The pull request alone adds over 197 thousand lines of code across 1,816 files. » I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting rema…

Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation. For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alon…

As a human (as far as I know...) there is a decent chance I'd write it like that, depending on the exact numbers.

It said "over 197 thousand". That's what I'd probably say for a number in [197000, 197999], or maybe "under 198 thousand depending on where it is in that range.

Saying "nearly 200 thousand" is still 3 digits so doesn't save any space over 197 or 198, and I think with it only being 3 digits most people will assume only the last digit is rounded. 200 ending in a string of 0s does suggest it might be rounded to the nearest 10 or nearest 100, but it just could easily not be.

I'd almost certainly fully write out 1816. If it were common to spell out groups below 1000 like 100s and were going to that I might write it as something like "just over 18 hundred" or "almost 19 hundred", but I almost never see anyone use grouping sizes of less than 1000.

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

#440

Post by inigyou » Sun, Jun 21, 2026, 1:33 AM UTC

tsimionescu wrote: post #177

inigyou wrote: post #173

Earlier quoted context omitted.

That's worse than null. Now every object has an invalid state. It works for Go because Go is trying to keep language complexity low. It has no good design principles behind it other than that. Also the zero value of a reference is null so you still haven't answered how a non-nullable reference field would work.

Sorry, I misinterpreted your question to be about non-nullable value classes, not non-nullable classes more generally. For reference variables, it seems that the a priori best approach would have been to generate a compiler error if the field was read before it was written; since this ship has long since sailed with final fields, it seems that the same approach would have to be taken - the "not null able" guarantee o…

The compiler doesn't solve the halting problem so it doesn't know whether a field is read before it's written.

If you allow a nonnull field to hold null at any point then it's trivial to leak that out and have nonnull variables holding null all over the program, which is obviously something to be avoided.

Maybe you can say that if you read a nonnull field when it's null, that throws an exception. That might have its own knock-on effects since nobody expects reading a field from a valid reference to throw an exception, but it might be the best way.