...

If a fiber is mounted, both the fiber and its carrier thread are basically the same execution context. If one is at a breakpoint, they both will appear to be at the same breakpoint. They will have the same stack traces, and single stepping in one advances the PC in the other. They are essentially two different views of the same Thread thread (with some minor exceptions in debugger behavior noted below).

...

Stack traces for fibers will include any scheduler related frames. For example, only the top free three frames below belong to the Fiber's implementation. The rest are considered to be scheduler related frames:

  [1] Main.taker (Main.java:29)
  [2] Main.lambda$static$2 (Main.java:35)
  [3] Main$$Lambda$7.1705736037.run (null)
  [4] java.lang.Fiber.lambda$new$0 (Fiber.java:161)
  [5] java.lang.Fiber$$Lambda$9.250421012.run (null)
  [6] java.lang.Continuation.enter0 (Continuation.java:233)
  [7] java.lang.Continuation.enter (Continuation.java:220)
  [8] java.lang.Continuation.run (Continuation.java:178)
  [9] java.lang.Fiber.runContinuation (Fiber.java:309)
  [10] java.lang.Fiber$$Lambda$10.295530567.run (null)
  [11] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec (ForkJoinTask.java:1,425)
  [12] java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:290)
  [13] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1,020)
  [14] java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1,656)
  [15] java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1,594)
  [16] java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:189)

...

If you single step while in the context of a fiber, execution flow will remain in the fiber even if you step over a method call that results in a yield, causing the fiber to be unmounted and later remounted on a different carrier thread. If you are in the context of the carrier thread when the fiber yields, the behavior is not well defined yet, and there are also known issues, especially when single stepping in and around Continuation.yield().

...

Debugging Support Limitations

There are a number of debugger features that are known to not work (or likely won't work) if you try them. They include (but are probably not limited to):

...

• fiberdebug=on: The debugger will see all fibers (this is what is currently implemented).
• fiberdebug=off: The debugger will not see any fibers. This will be useful when using a large number of fibers and not needing any fiber specific debugging support.
• fiberdebug=partial: The debugger will only see interesting fibers. For example, fibers that have reached This will be useful when using a large number of fibers, and only needing to debug some fibers. The fibers that will be visible will be the ones that some sort of event has happened on, such as a breakpoint. This would, for example, allow you to single step in a fiber that you hit a breakpoint in, but would not bog require that the debugger down with a large number of fibersknow about every fiber.

Miscellaneous Implementation Details

...

For this first version of Fiber debugger support, we decided not to make any changes the JDWP or JDI, and therefore no changes are needed in the debuggers. There are some JVMTI additions that provide the Debug Agent with events to indicate Fiber start/terminate and also mount/unmount. There are also new JVMTI APIs that allow getting the Fiber running on a Carrier Thread (if one is running), and to get the Carrier Thread a Fiber is mounted on (if it is mounted).

...