5 ms·

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

jerf 3y ago
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.
- deleted 3y ago
  [deleted]
- layer8 3y ago
  They’ll have to implement java.lang.Thread somehow, or not a lot will run on that JVM.
  - samus 3y ago
    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)
  - andrewbinstock 3y ago
    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.
- twic 3y ago
  I concur. Native methods have hardcoded implementations, wired up here, and there is nothing for java.lang.Thread: https://github.com/platypusguy/jacobin/blob/18c541820cb73bdaab24ea4b52a4221273dd84ac/src/classloader/mTable.go#L75 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.
- andrewbinstock 3y ago
  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.
  - returningfory2 3y ago
    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?
    - andrewbinstock 3y ago
      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.
    - jerf 3y ago
      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.
      - returningfory2 3y ago
        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...
    - tracker1 3y ago
      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.
suumcuique 3y ago
Project Loom is not included in JDK17.

jerf 3y ago

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.

deleted 3y ago
[deleted]
layer8 3y ago
They’ll have to implement java.lang.Thread somehow, or not a lot will run on that JVM.
- samus 3y ago
  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)
- andrewbinstock 3y ago
  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.
twic 3y ago
I concur. Native methods have hardcoded implementations, wired up here, and there is nothing for java.lang.Thread: https://github.com/platypusguy/jacobin/blob/18c541820cb73bdaab24ea4b52a4221273dd84ac/src/classloader/mTable.go#L75 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.
andrewbinstock 3y ago
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.
- returningfory2 3y ago
  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?
  - andrewbinstock 3y ago
    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.
  - jerf 3y ago
    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.
    - returningfory2 3y ago
      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...
  - tracker1 3y ago
    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.

suumcuique 3y ago

Project Loom is not included in JDK17.