[External] : Re: ClassNotFoundException for Custom Scheduler Prototype v2

[Mengyang Li]

Hi Alan,

Thanks for the quick reply. I’ll continue investigating the custom
scheduler and sun.nio.ch.Poller related code.

I also checked the Loom repo’s io_uring branch and noticed a difference
when io_uring poller is enabled:


   -

   SocketChannelImpl still does park(Net.POLLIN) then IOUtil.read(...)
   -

   NioSocketImpl (for virtual threads) does:

``` java
if (Poller.supportReadOps() && Thread.currentThread().isVirtual()) {
    n = Poller.read(fdVal(fd), b, off, len, remainingNanos, this::isOpen);
    if (n != IOStatus.UNAVAILABLE) return n;
}
```

Why isn’t SocketChannelImpl using a similar Poller.read(...) VT path? Is
this intentional, or just not wired up yet in that branch?

Best regards,
Mengyang Li


Alan Bateman <alan.bateman at oracle.com> 于2026年2月26日周四 15:20写道：

>
>
> On 26/02/2026 02:49, Mengyang Li wrote:
>
> Hello everyone, With “Custom Scheduler Prototype v2”, the JDK loads the
> class specified by jdk. virtualThreadScheduler. implClass via the internal
> AppClassLoader. This works for typical apps, but fails for Spring Boot fat
> JARs where the application
>
> :
>
> Would it be feasible to switch to an SPI  (similar to JDBC) so custom
> schedulers are pluggable under non-standard class loaders? Potentially the
> same approach could apply to a pluggable Poller API.
>
> In this prototype, the scheduler is configured system-wide and cannot be
> changed mid-flight. It has to be visible to the application class loader,
> otherwise there would be no way to schedule virtual threads before the
> custom class loader is created. It can be re-visited if efforts in this
> area go further than the prototype. For now, the custom scheduler has to
> deployed on the class path or module path.
>
> There is no Poller API. The class that I think you have found the JDK
> internal class that supports blocking operations when using the Socket and
> other networking APIs. It's not something that we want to expose in any
> way. If the context for your comment is a library that does syscalls
> directly (FFM or JNI) then the "primitive" that it can use to park/unpark
> virtual threads is LockSupport.park/unpark, it does not need Poller.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260227/38e0dd3c/attachment-0001.htm>