It should not be possible for threads to monopolize computation

[TimAbraldes]

In particular, it should not be possible for any thread to starve the GUI thread.

This has become salient in the StressBench test after #1484 is applied and in the SchedulerBench created in #1729

[mbebenita]

Impossible, unless we add preemption checks at all loop headers. Which we could do, quite easily.

[mykmelez]

Impossible, unless we add preemption checks at all loop headers. Which we could do, quite easily.

Let's do it.

[TimAbraldes]

Impossible, unless we add preemption checks at all loop headers. Which we could do, quite easily.

For some reason I thought we were already doing this. What kept us from adding these? Perf impact on compiled code?

It's definitely compiled code that's blocking preemptions, otherwise the "Bytecode" output in the below run would be higher than the "iterations" count from "hi4".

When I run the benchmark from #1729 I see this: Bytecode: 8,326 Compiled: 7/0/103/0 Interpreter: 280 OSR: 5 Unwind: 12 Preemption: 0

and this: 1.2:20.5 | Thread hi4 completed 65131215 iterations 1.2:19.5 | Thread med4 completed 1 iterations 1.2:18.5 | Thread lo4 completed 1 iterations 1.2:17.5 | Thread hi3 completed 1 iterations 1.2:16.5 | Thread med3 completed 1 iterations 1.2:15.5 | Thread lo3 completed 1 iterations 1.2:14.5 | Thread hi2 completed 1 iterations 1.2:13.5 | Thread med2 completed 1 iterations 1.2:12.5 | Thread lo2 completed 1 iterations 1.2:11.5 | Thread hi1 completed 1 iterations 1.2:10.5 | Thread med1 completed 1 iterations 1.2:9.5 | Thread lo1 completed 1 iterations 1.2:8.5 | Thread hi0 completed 1 iterations 1.2:7.5 | Thread med0 completed 1 iterations 1.2:6.5 | Thread lo0 completed 1 iterations 1.2:2.10 | In 36429ms, 1 frames were rendered for an FPS of 0

EDIT: I had initially said that it wasn't clear whether the interpreter or the compiler was responsible for preemption blocking but it's definitely the compiler. Updated comment to reflect that.