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

401–410 of 464 posts

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

#401

Post by wffurr »

cenamus wrote: post #267
tennfown wrote: post #220

Earlier quoted context omitted.

> Embedded systems? Like sim cards? Serious question: I remember the old installer, six billion devices or whatever. I’ve heard about Java ME, old set-top boxes and DVD players, etc. But how much of that is active today. I can’t say I’ve ever seen a job listing for an embedded Java developer or even Java ME in my entire career. Are people actually still using it?

Yeah I didn't mean it as praise for Java (SE, ME, or whatever), but I don't think you're better off finding embedded WebAssembly jobs

https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/WebAssembly/wabt/blob/main/wasm2c/README....

ISTR Siemens uses wasm2c to compile Wasm for a bunch of embedded devices runninng Zephyr RTOS.

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

#402

Post by DarkNova6 »

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…

It is beyond me why I would get downvoted for legitimately pointing out shortcomings. I find it honestly frustrating how some people believe that “their language is best”. Until you point out real existing inconsistencies…

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

#403

Post by aardvark179 »

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

Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads.

The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.

Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.

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

#404

Post by kuhsaft »

gf000 wrote: post #399
kuhsaft wrote: post #357

Earlier quoted context omitted.

I made a comment on my understanding of the difference in implementation here: https://news.ycombinator.com/item?id=48606173 The ramifications for backwards compatibility is that the JVM won't have CLR features such as stackalloc (allocation of blocks of memory on stack), ref parameters (pass-by-reference of stack allocated value types), and all the other low-level/high-performance programming features available in t…

> allocation of blocks of memory on stack) Why couldn't it be done? Like sure, it won't happen in every case (e.g. too big value classes), but for a typical local variable of a value type, it's a trivial optimization to make it stack allocated. Even now it happens quite often (requires escape analysis), but the semantics change of value classes allows for it to be done "freely".

C# stackalloc returns a ‘ref struct’ which has certain restrictions and would be a Q-world type.

Java chose to go with an L-world implementation where everything is still a reference type on the heap, but memory management is more efficient via flattening. That’s why it’s a ‘value class’ and not a ‘struct’.

Primitive wrappers are scalarized into registers.

Stack allocated value types would have different semantics and is incompatible with the L-world implementation. Sure, they could implement it, but it would be the Q-world implementation that they decided to forego.

They can do automatic stack allocation for optimization via escape analysis as you mentioned. But, stackalloc is user allocated.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

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

#405

Post by kuhsaft »

pjmlp wrote: post #392
WorldMaker wrote: post #354

Earlier quoted context omitted.

IronPython did just fine with reified generics.

Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR. Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.

Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast.

I suppose DLR would be comparable to GraalVM/Truffle.

The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations for memory management.

I think an interesting project would be to implement a CIL interpreter on GraalVM.

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

#406

Post by [deleted] »

steveklabnik wrote: post #179
gf000 wrote: post #46

Earlier quoted context omitted.

Actually, Java only has pass-by-value, even for reference types. (The same way as C does). People really misuse/misunderstand this term: Java objects are passed by their pointers ("references") being copied. The alternative is pass by reference, which is done by e.g. c++, rust, who actually have references (Java doesn't). A good litmus test is whether you can write a swap method that actually changes your local varia…

Rust is also “pass reference by value,” not pass by reference.

[deleted]

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

#407

Post by pjmlp »

kuhsaft wrote: post #405
pjmlp wrote: post #392

Earlier quoted context omitted.

Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR. Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.

Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast. I suppose DLR would be comparable to GraalVM/Truffle. The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations…

DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used.

GraalVM already handles LLVM bitcode, much cooler than plain MSIL.

And here there is another example where Java ecosystem ends up being better.

MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM style, instead it died and what is left are a couple of research papers.

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

#408

Post by jayd16 »

gf000 wrote: post #381
jayd16 wrote: post #359

Earlier quoted context omitted.

This is pretty funny... "All differences are opinions....except what .net did. Those are wrong!" I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again. Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse. It's probably exactly because of the "not like .NET! We must be different to explain being late…

Both languages/runtimes are decent, stable and good choices for running production systems. They have different philosophies though, C# is mostly "give the developer a complex toolkit so they can do whatever they want, but keep the runtime simple", while Java is more like "keep the language as simple as possible, and put new features mostly into the runtime making it more complex, but benefiting even old code". Async…

I do think Java is a fine language but I don't really agree that it looks more simple in any way shape or form.

For things like UI programming where you need a main thread or where you do need a cross language OS thread, I think Java is going to end up more complex. Under the hood it is very complex and that _will_ show itself.

So from my perspective it's not virtual threads, it's virtual threads with structured concurrency vs async/await. When you look at it that way, the comparison of complexity is certainly not seamless or simple.

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

#409

Post by jayd16 »

pron wrote: post #396
jayd16 wrote: post #359

Earlier quoted context omitted.

This is pretty funny... "All differences are opinions....except what .net did. Those are wrong!" I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again. Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse. It's probably exactly because of the "not like .NET! We must be different to explain being late…

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

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

#410

Post by Dylan16807 »

Joker_vD wrote: post #394
Dylan16807 wrote: post #386

Earlier quoted context omitted.

Left shifting a large positive number is also UB. C made a lot of things undefined that would make much more sense as implementation defined.

Yep. Basically, if you take a signed int/long/etc. and a set bit shifts left into the sign bit — UB. > a lot of things... would make much more sense as implementation defined. Or even just defined. Apparently, the fact that shifting right a signed number is done arithmetically, not logically, is implementation-defined too. Well, at lest bitwise not/and/or are (almost) fully defined even for signed integers, so that's…

Well at the time it made sense not to force two's complement. But I would try harder to trim the UB list over time.
Post reply on HN