diff --git a/index.html b/index.html index 5ebc0dab35..d149e79f22 100644 --- a/index.html +++ b/index.html @@ -1290,8 +1290,22 @@
  • add -Dcask.virtual-threads.enabled=true to your JVM options, which is needed to enable the virtual threads.
  • tweak the underlying carrier threads with -Djdk.virtualThreadScheduler.parallelism, jdk.virtualThreadScheduler.maxPoolSize and jdk.unparker.maxPoolSize.
    • -

    Advanced Features: 1. You can change the default scheduler of the carrier threads with cask.internal.Util.createVirtualThreadExecutor method, but keep in mind, that's not officially supported by JDK for now. 2. You can supply your own Executor by override the handlerExecutor() method in your cask.Main object, which will be called only once when the server starts. 3. You can use jdk.internal.misc.Blocker's begin and end methods to help the ForkJoinPool when needed.

    -

    NOTE: 1. If your code is CPU-bound, you should not use virtual threads, because it will not improve the performance, but will increase the overhead. 2. A common deadlock can happen when both a virtual thread and a platform thread try to load the same class, but there is no carrier thread available to execute the virtual thread, which will lead to a deadlock, make sure jdk.virtualThreadScheduler.maxPoolSize is large enough to avoid it. 3. Virtual thread does some kind of rescheduling which may lead to higher latency when the task is actually cpu bound. 4. OOM is a common issue when you have many virtual threads, you should limit the max in-flight requests to avoid it. 5. There are some known issues which can leads to a deadlock, you should be careful when using it in production, at least after long time stress test. 6. JEP 491: Synchronize Virtual Threads without Pinning will be shipped in Java 24. 7. Some info from early adaptor faire

    +

    Advanced Features:

    +
      +
    1. You can change the default scheduler of the carrier threads with cask.internal.Util.createVirtualThreadExecutor method, but keep in mind, that's not officially supported by JDK for now.
      2. +
    2. You can supply your own Executor by override the handlerExecutor() method in your cask.Main object, which will be called only once when the server starts.
      3. +
    3. You can use jdk.internal.misc.Blocker's begin and end methods to help the ForkJoinPool when needed.
      4. +
    +

    NOTE:

    +
      +
    1. If your code is CPU-bound, you should not use virtual threads, because it will not improve the performance, but will increase the overhead.
      2. +
    2. A common deadlock can happen when both a virtual thread and a platform thread try to load the same class, but there is no carrier thread available to execute the virtual thread, which will lead to a deadlock, make sure jdk.virtualThreadScheduler.maxPoolSize is large enough to avoid it.
      3. +
    3. Virtual thread does some kind of rescheduling which may lead to higher latency when the task is actually cpu bound.
      4. +
    4. OOM is a common issue when you have many virtual threads, you should limit the max in-flight requests to avoid it.
      5. +
    5. There are some known issues which can leads to a deadlock, you should be careful when using it in production, at least after long time stress test.
      6. +
    6. JEP 491: Synchronize Virtual Threads without Pinning will be shipped in Java 24.
      7. +
    7. Some info from early adaptor faire
      8. +

    Some benchmark results: