Project Loom, and fibers

[ws909]

Question

Java is about to have a number of new features integrated, some of which are:

• Virtual threads (fibers) (Loom)
• Value types (Valhalla)
• Primitive types (Valhalla)
• Universal generics (Valhalla)
• Foreign function and memory API (Panama)
• Vector API (Panama)

It has been mentioned in previous issues that some of these features (Panama) will require such extensive rewriting of LWJGL, that LWJGL will be transitioned into version 4. However, as several of these have been available as incubator features for a while, and are now transitioning to preview features, new projects utilizing LWJGL will want to take advantage of them. Many existing projects would also benefit from them.

What issues currently exist, that will cause problems with, or prevent projects from, using these new features with LWJGL?

1. Which LWJGL APIs are not safe to use with these new features?
2. Is the MemoryStack API safe to use in virtual threads?
3. Certain libraries unnecessarily perform blocking calls in addition to data processing, on the calling thread. Would these APIs be problematic from virtual threads? The OpenJDK team may be better fit for answering such a question.
   • STBI loads images from file paths. Loom-safe file loading can be achieved by using stbi_load_from_memory instead.
   • ShaderC processes GLSL files that can link to other GLSL files on the system.

I assume I can add more questions once they pop up in my head.

[octylFractal]

1. To my knowledge, all of LWJGL should be safe to use with the new features. Obviously Panama can't be used with LWJGL until LWJGL itself is rewritten to be based on it, but the feature existing does not prevent LWJGL from working. The only issue that might occur is with virtual threads -- the threading requirements of some libraries in LWJGL will refer to the platform thread, so as long as all your virtual threads use the same platform thread, they will be thread-safe / using the "same" thread with respect to LWJGL. However, code that runs on a single virtual thread, but switches to different platform threads, will not be thread-safe / [...] in that regard.
2. I see no reason that MemoryStack would not be safe to use from virtual threads.
3. These APIs will be problematic from virtual threads, as specified by JEP 425 native calls (i.e. JNI and Panama) will pin the virtual thread to its platform carrier thread. Other than potentially reducing parallelism, there should be no issues.

[ws909]

@octylFractal

1.

• I am very much looking forward to a refined LWJGL taking advantage of the new Valhalla and Panama features. I already have used some of the new FFI features when working with LWJGL bundled libraries, as I prefer their interface over NIO.
• I do not know how to guarantee that certain virtual threads run on a specific OS thread. I therefore assumed virtual threads may have to be completely omitted for code calling libraries/frameworks like GLFW.
  3. Ah, of course, I forgot that the implementation of ThreadLocal assigns a new MemoryStack to each thread, which, in this case, will include virtual threads. I was worried it would be tied to the OS thread, meaning virtual threads' stacks would overlap, but of course they won't.
  4. The changes in JEP 425, to JNI, only include adding IsVirtualThread, which will be of little to no use, as these libraries don't use JNI themselves. The issue besides reducing parallelism is that these calls won't necessarily just reduce it, but may stall it entirely. If all the Fiber OS threads are waiting on IO or similar, that may block all execution of other virtual threads.

[octylFractal]

Re (3), you should be able to manually wrap these I/O methods in ForkJoinPool.managedBlock(...) in order to avoid starving the virtual thread executor. As the JEP specifies, virtual threads are run using an internal ForkJoinPool.

[ws909]

@octylFractal Thanks. Apparently, I missed all of it. I read most of the newer JEPs, so I may have come across it a good while ago, but didn't recall that now.