Overview

Support for debugging Fibers has been partially implemented. Fibers will appear to the debugger as ordinary threads. When you view the list of threads from within the debugger, you will see both fibers and the carrier threads they run on. Depending on the debugging mode, not all fibers may appear in the thread list. See Fiber Debugging Modes below.

...

ForkJoinPool-1-worker-3
ForkJoinPool-1-worker-1
Fiber@5a1fbaa6[<no carrier thread>]
Fiber@50e7d1d6[ForkJoinPool-1-worker-3,CarrierThreads]
Fiber@5e2035ba[ForkJoinPool-1-worker-1,CarrierThreads]

Single Stepping

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().

Fiber Stack Traces

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

...

In this case frames 7-10 (and actually also 5-6) are considered fiber frames. The frames above it are just there to support temporarily mounting the fiber. This will be improved in the future.

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):

• Suspending or resuming a specific fiber. When the debugger asks for all threads to be suspended (which is usually what happens at breakpoints), the fibers will also be considered suspended. However, do not try to suspend a specific fiber, or resume any fiber that was suspended as a result of suspending all threads.
• Setting local variables in fibers (you can view them). This actually applies to fiber frames, even if the current thread is a carrier thread. More specifically, you cannot set locals in continuation frames.
• Dealing with a large number of fibers. For one, you will overwhelm the debugger because it will see them all. Also, fibers are not tracked in an efficient manner by the debug agent, so it can also become bogged down.
• Forcing a fiber frame to return ("Drop Frame" in Intellij), although this should work fine if executed from the carrier thread context instead of the fiber context.

Fiber Debugging Modes

By default the debugger is only notified of fibers for which certain events have arrived on (breakpoint, exception, and watchpoint being the most notable). This is necessary when debugging a vary large number of fibers, because you wouldn't want every single fiber to appear as a thread in the debugger. This behavior can be overridden with the "fibers" option passed on the command line to the debug agent.

• fibers=all: The debugger will see all fibers. Use only when you have a manageable number of fibers, and you don't mind all of them appearing in the debugger's thread list.
• fibers=n: The debugger will not see any fibers. Use this option when using a large number of fibers and not needing any fiber specific debugging support (like single stepping through a fiber as it switches carrier threads).
• fibers=y: This is the default. The debugger will only see fibers for which certain events have arrived on. This will be useful when using a large number of fibers, and only needing to debug some fibers. The debugger will become aware of a fiber when certain events arrive on it, such a breakpoint, watchpoint, or exception. Once one of these events arrives, you can then single step through the fiber code, even as it switches carrier threads.

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).

...