isInterruptRequested

Answer true if an interrupt has been requested. The interrupt may be specific to the current fiber or global to the runtime. There are several reasons why an interrupt might be requested:

• A safe point might be requested by the runtime, to ensure no fibers are executing during a critical operation, such as adding a method definition. This requires more than just a lock, since it will cause L2Chunks that rely on that method to be invalidated, which would not work if those chunks were running. Reified continuations that get built for such chunks always check for validity when they're resumed, allowing them to downgrade safely to the default chunk that runs the L1 interpreter.

• The stack might be deeper than the maxUnreifiedCallDepth. This is currently measured by number of Avail function calls. A reification of the frames from the JVM stack effectively resets this to zero without affecting program semantics, allowing interpreter stacks to be bounded. This is not just to support deep recursion, but to ensure any interrupt can reify the stack in a reasonable time.

• The current clock tick counter may indicate that more than timeSliceTicks have elapsed since starting or resuming the current fiber. In that case, a task to resume the fiber should be queued, and the next eligible fiber should be run (which might end up being the current fiber again).

• The REIFICATION_REQUESTED flag may have been set on the current fiber. This mechanism allows a fiber to efficiently poll another fiber's current A_Continuation periodically. Note that the reified continuation is always made Shared in this situation, so that both fibers will be able to access the state safely.

Return

true if an interrupt is pending, false otherwise.