Top
Best
New

Posted by philonoist 13 hours ago

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28(www.jvm-weekly.com)
478 points | 277 commentspage 3
maelito 8 hours ago|
What I have in mind when I read Valhalla : https://valhalla.openstreetmap.de/
ahartmetz 12 hours ago||
From the article:

> In 1995, a memory access cost roughly the same as a CPU operation

Uhm... no?!

Here's a CS paper from 1993(!) about prefetching from cache(!!) because the cache was slower than the ALU. https://www.eecs.umich.edu/techreports/cse/93/CSE-TR-152-93....

It would perhaps make Java look a little bad to say that, in 1995, the prevailing attitude in certain circles was "If it's too slow, just wait for faster hardware - Moore's Law forever baby!" (Of course, Sun was selling, at the time, relatively fast hardware - the slower the software, the faster the required hardware)

rob74 8 hours ago||
Yeah, when I read that, I thought "this guy was either born wayyy after 1995, or he doesn't know the first thing about computer hardware history, or both". 1995 was the year the Pentium Pro was launched, which was (one of?) the first CPU(s) to integrate the L2 (!) cache into the same package as the CPU - they were still separate chips, but the interconnection could be made faster by putting them into the same package.
tialaramex 6 hours ago||
Yeah, 1995 is much too late. I'd say somewhere about 1990. Maybe you can go as early as the i386 and 68030 in the late 1980s but I'd be hesitant to include them.
Athas 11 hours ago||
Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!
ahartmetz 11 hours ago|||
Early 80s is also what I remember, mainly from articles about old CPUs on HN - like the zero page on the 6502 that served as a sort of L2 register file.
dboreham 6 hours ago|||
Well, yes but no:

The Z80 took 3 cycles to load from memory. A register to register transfer took 4 cycles (including fetching the instruction). Only one of those cycles was instruction execution.

I think the only reasonably mainstream scenario where the CPU would be significantly slower than memory would be the serial CPU designs such as the PDP-8/s.

That said, at the time people were doing cool stuff with 8-bit CPUs, they weren't running software remotely like what we're discussing here. That would have been done on a VAX, which had instruction and data caches.

What really happened, that the article is alluding to is that memory didn't get much faster in absolute terms since the 1980s. CPUs on the other hand did.

E.g. in the 1980s we had 60ns DRAM. Today DDR5 I believe allows about 10ns random access reads best case (6X). Over the same period CPU clock speeds have increased from about 8MHz to 5GHz (600X).

newsoftheday 5 hours ago||
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?
jeroenhd 4 hours ago||
JDK 21 is a few years old now, so you were a few years behind. JDK 25 was released last year, which makes for the next stable LTS for a while. JDK 28 is expected in 2028, and these features are not going to be enabled by default for years after that.

Java is generally backwards compatible, so unless you're using fat frameworks that use shady internals or known-deprecated APIs, you should generally be fine immediately upgrading to the latest LTS, possibly even non-LTS versions if you have confidence in your stack.

cogman10 5 hours ago|||
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.

bpodgursky 4 hours ago||
How much stuff actually broke? I feel like you can treat Java upgrades as minor upgrades most of the time, maybe you have to rebuild a few binaries but I'd be shocked if it required significant code changes.
drzaiusx11 7 hours ago||
Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...
exidex 2 hours ago||
Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though
mattstir 6 hours ago|||
That's true for arrays of these value classes. Scalarization would help for larger local values though, since those would avoid pointer indirection for purely local values.
logicchains 3 hours ago|||
Surely it can't be that, it destroys basically the entire value proposition of value types, unless you use a preprocessor to write everything as SOA.
lowbloodsugar 4 hours ago||
And one bit for null! So “smaller data types” means 32bits! Yay! It’s 1995 again!
nasso_dev 10 hours ago||
stopped reading when i saw the AI illustration. wholly unnecessary, and it feels insulting to be fed slop like this...

if you really want a fun drawing get a human artist to do it. it doesn't need to be complicated, for example https://www.code-cartoons.com/ is mostly just stick figures and does an excellent job

but you don't even need any of that, a mermaid diagram would have worked perfectly fine too. instead you chose to use a technology that is known to be harmful

jeroenhd 3 hours ago||
I simply do not trust articles that use slop imagery like this. I assume the text of this article (and realistically, most articles posted here) is also slop, but it's often difficult to tell.

If you don't have the time or put in the effort to make your article, I'm not going to spend time and effort reading it. You really don't need some generic cartoon guy hovering over your graphs, draw them in MS paint or something.

piiritaja 6 hours ago||
Thank you, no idea how this stuff gets upvoted here. The whole article reads like something Claude came up with.
Hendrikto 8 hours ago||
> The pull request alone adds over 197 thousand lines of code across 1,816 files.

And that across 2819 commits.

Wow, that’s insane.

nu11ptr 6 hours ago||
I'm a little unclear as to when and under what conditions this results in non-heap objects, now (<= 64-bits?) and in the future (???). I thought that was the _ENTIRE_ point of this project, so I was surprised to see they can be null (did that change from before?). If it is always and forever limited to 64-bits, I fail to see the point of this entire project, as it would have been far simpler to add syntactic sugar (simply pass primitives underneath the covers) as Scala did to create value types vs. JVM changes.
cyberax 1 hour ago||
Does it FINALLY fix the "-Xmx" nonsense? Or do I still have to statically specify the max heap size, as if I'm still using MacOS 9?
aykutseker 11 hours ago||
I think a lot of people will file this under Java got structs.

That seems off. They're still objects, the new thing is that they can give up identity.

pregnenolone 10 hours ago|
Looking into the negative comments is quite amusing. Not only do most of them contain technical inaccuracies, but of course, they also need to mention how great .NET supposedly has been from the beginning and how Java supposedly copied everything.

Let's take a stroll down memory lane. First of all, .NET literally started as a Java copy. On top of it, a non-cross-platform one for almost two decades! After having shamed Linux for so long Microsoft finally started porting .NET to other platforms in a non-backward compatible way. A lot of .NET proponents will tell you porting from legacy .NET to .NET Core (which was renamed once again to .NET) would be a quick fix, but it isn't. For example, the shop I used to work in had some important cryptographic libraries which were very painful to port. And then, there's .NET's simplistic garbage collector, which can be quite annoying because it tries to be a one-fit-all solution that basically cannot be tweaked at all, often resulting in unresolvable latency problems. There’s a lot of other stuff, like its ghetto-like ecosystem and the insane fragmentation of GUI libraries.

I also don't get the C# praise. Over the years, it has become quite the bloated language. It feels like Microsoft tries to implement every feature possible without realizing that an enterprise language is supposed to be streamlined. Async/await? Very ugly, very annoying. Java has solved this a lot better with virtual threads and structured concurrency.

I could go on, but these "language wars" are silly and pointless. Both platforms have their pros and cons. Besides, I have a lot of bad things to say about the JVM as well, but it's nice to see Valhalla finally beocming reality. Too late for me personally though.

ozim 9 hours ago|
I like how you point out inaccuracies and next paragraph you deliver couple more, finishing with “language wars are silly and pointless”.
pregnenolone 9 hours ago||
> inaccuracies

Like what?

ozim 3 hours ago||

  legacy .NET to .NET Core (which was renamed once again to .NET)  
It was always .NET, only that new one had 1 till 4 had additional "Core" to clarify any confusion that could come from having same numbers as old.

  here's .NET's simplistic garbage collector ... it tries to be a one-fit-all solution that basically cannot be tweaked at all  
Definitely tweaking GC is not a thing in .NET land but it is far from "cannot be tweaked at all".
More comments...