Hacker News Reader

Comment by lopatin | Hacker News Reader

I wonder if it uses Go routines as the virtual threads implementation.

If I am reading the code correctly, and as a parachute code reviewer I may very well not be, I am not sure this supports threading at all, or at least, not user-level threading.

I can find references to a thread module and it clearly creates a "main" thread, but I actually can't find anywhere where it creates anything other than a main thread, nor do I see any code for task switching manually/cooperatively, or anything else like that. There's a global thread table but I can only find test code manipulating it. And the main core VM loop doesn't seem to have any concurrency in it to me.

Corrections welcome; posted fully in the spirit of Cunningham's Law as I'm curious too.

They’ll have to implement java.lang.Thread somehow, or not a lot will run on that JVM.

Correct, implementing the core libraries is actually a massive effort. You can't just take the Hotspot one because it is a massive cumbersome codebase and it would force your JVM to work like Hotspot internally. (Let's ignore for a moment the question whether that would even be legal)

Lead dev here. Yup, that's right. There are a few classes that we will be forced to implement in Go. We're fixated on keeping this number as low as possible, but Thread is one that is inescapable. Class is another inescapable one--if we're to support reflection, etc.

I concur. Native methods have hardcoded implementations, wired up here, and there is nothing for java.lang.Thread:

https://github.com/platypusguy/jacobin/blob/18c541820cb73bda...

I couldn't figure out what happens if you invoke a native method that has not been set up like this.

Author here. No threading currently. Once we have all the bytecodes executing, we will perforce be obliged to add threading. Starting with the heavier threading that Java pre-Loom uses.

Can you just use green threads (goroutines) from the get-go? Or, by Hyrum's law, is the fact that legacy Java threads are really OS threads part of Java's de facto public API?

That's a good question. I don't know enough about the new green threads to give you a definitive answer, but it's certainly something we'll examine closely.

You have to distinguish between the implementation and the interface from the Java point of view. In Go, you'd use goroutines. Even if you want to use an OS thread you use a goroutine and then pin it to an OS thread, and there's no reason to do that in this case.

However, inside Java it may look like the original Threading API. In that case you'd have a JVM running the Thread abstraction in Java on top of green threads in Go, while not supporting Java green threads, and there's no contradiction or even anything weird going on. Perfectly normal.

Right right, but I wonder if there is some weird edge case where some Java program relies on threads being real OS threads...like, for sure Java threads being OS threads is an observable feature of a running Java program (you can see it in htop!). And maybe someone has built a Java based system somewhere that uses that...

I recall seeing some really hacky Java implementations that used thread references for state management... Mostly, in that the same devs expected the same experience in the C# ASP.Net lifecycle and it lead to a lot of wierd race bug conditions in practice.

Project Loom is not included in JDK17.

Reply on news.ycombinator.com