[19] Project Loom support

[iloveeclipse]

Continuation from https://bugs.eclipse.org/bugs/show_bug.cgi?id=572000.
Probably need to be considered in context of eclipse-jdt/eclipse.jdt#10

Got an update from Alan Bateman:

We've made a lot of progress since last year and are planning to
integrate the "Virtual Threads" feature into JDK 19. The JEP with all
the details is JEP 425 [1] and is currently "proposed to target". All
going well we should be able to integrate into the the JDK main line
within the next few weeks. In the mean-time, we have early access builds
and online docs [2].

For the debugger there are updates to JDI, JDWP, and JVM TI. My memory
is that Eclipse has its own JDI implementation and you need to track
changes to both JWDP and JDI. If Eclipse is already working with JDK 19
EA builds then I expect it will mostly work with the Loom EA builds too.
There are some differences, e.g. VirtualThread::allThreads will only
enumerate the platform threads by default, ThreadGroupReference::threads
only enumerates platforms because virtual threads are not members of a
thread group, ThreadReference::stop is specified to throw UOE on virtual
threads. All the details are in the javadoc (the JDWP protocol spec [3]
is online too, but the link from the API docs is hard to find sometimes).

Anyway, this just a heads-up that this feature is coming.

[1] https://openjdk.java.net/jeps/425
[2] https://jdk.java.net/loom/
[3] https://download.java.net/java/early_access/loom/docs/specs/jdwp/jdwp-protocol.html

[SarikaSinha]

https://bugs.openjdk.java.net/browse/JDK-8277131
The updates to JDWP are:

A new command allows debuggers to test if a thread is a virtual thread.

A new modifier on the EventRequest command allows debuggers to restrict thread start and end events to platform threads.

The updates to JDI are:

A new method in com.sun.jdi.ThreadReference tests if a thread is a virtual thread.

New methods in com.sun.jdi.request.ThreadStartRequest and com.sun.jdi.request.ThreadDeathRequest limit the events generated for the request to platform threads.

jdi interface package was removed via :

• Bug 565417 - package com.sun.jdi is accessible from more than one module

Now the biggest question is how will debug support new APIs from JDI without moving to Java 19 dependency ?
@iloveeclipse any thoughts?

[iloveeclipse]

Some thoughts that came to my mind:

• Have JDI interfaces used for build only (not exported & not shipped) ? Similar what we have with https://github.com/eclipse-jdt/eclipse.jdt.core/blob/21b1f9d0bd80d28d7df6e72b1186625a273e2134/org.eclipse.jdt.compiler.tool/.classpath#L5
• Fragment that depends on Java 19+ ?
• Reflection to access 19+ API ?

[SarikaSinha]

Some thoughts that came to my mind:

• Have JDI interfaces used for build only (not exported & not shipped) ? Similar what we have with https://github.com/eclipse-jdt/eclipse.jdt.core/blob/21b1f9d0bd80d28d7df6e72b1186625a273e2134/org.eclipse.jdt.compiler.tool/.classpath#L5
• Fragment that depends on Java 19+ ?
• Reflection to access 19+ API ?

Will not favour Reflection if we have other option.
Stub lib jar should serve the purpose but will have maintenance overhead.
Will explore fragments.

[SarikaSinha]

When I see swt binaries fragments, They load based on osgi os, ws and arch filters with Eclipse-PlatformFilter.
I could not find any filter for java versions, can we add filters?
Or there are other ways to do it?

[testforstephen]

@iloveeclipse @SarikaSinha I'm the maintainer of VS Code Java Debugger extension, which uses JDT JDI implementation as the sdk to communicate with the debuggee. Recently I'm also looking into how to enable the virtual threads support in JDT and VS Code Java Debugger.

Now the biggest question is how will debug support new APIs from JDI without moving to Java 19 dependency ?

I don't think this will stop us from adding these new methods to the Eclipse JDI XxxImpls even if we're using JDK 11 JDI interfaces. For example, we could still implement a method ThreadReferenceImpl#isVirtual() and have it talk to the JVM by using the new JDWP command, since JDWP commands do not depend on the JDI.

One drawback is that we have to use XxxImpl to access these new capabilities instead of interfaces.

[SarikaSinha]

Currently I see the usage of com.sun.tools.jdi.ThreadReferenceImpl.isVirtual() at 2 places (apart from example) :
org.eclipse.jdi.internal.ThreadReferenceImpl.popFrames(StackFrame)
org.eclipse.jdi.internal.ThreadReferenceImpl.forceEarlyReturn(Value)

I don't see any change done in ThreadStartRequestImpl and ThreadDeathRequestImpl as of early access build 23 of java 19.

As the changes are minimal, it can be done by doing the changes in Impl file only as suggested by @testforstephen

[testforstephen]

@SarikaSinha Yes, this seems feasible. Do you know of anyone working on this? If not, I'm willing to start a PR to implement this on JDT JDI.

[SarikaSinha]

@SarikaSinha Yes, this seems feasible. Do you know of anyone working on this? If not, I'm willing to start a PR to implement this on JDT JDI.

Yes, you can start on this.

[vik-chand]

I unpinned this issue by mistake ( i thought it was a pop-up and most obvious/natural thing to do is to press x). Pinned it again

[AlanBateman]

JDK 19 is currently in Rampdown Phase One. P1-3 bugs can be currently be fixed so this would be good time to report any issues that you might have with JVM TI, JDWP or JDI before it gets too late in this release.

[testforstephen]

@AlanBateman Thanks for the update. I'm currently working on getting JDT JDI library to support virtual threads. I already have a draft PR #76, and will try to finish it in the coming weeks.

[SarikaSinha]

Main support is done, rest of the issues can be tracked via a separate issue.