Remove final fields startIO and startEC

[vasilmkd]

Because we used startIO and startEC as part of execR, this escaped the constructor of IOFiber and the constructor arguments became (final) fields after compilation, resulting in unnecessary bloat to each fiber. On top of that, we were unnecessarily holding onto the root IO object, for the whole lifetime of the fiber.

Before:

Compiled from "IOFiber.scala"
public final class cats.effect.IOFiber<A> extends cats.effect.IOFiberPlatform<A> implements cats.effect.kernel.Fiber<cats.effect.IO, java.lang.Throwable, A>, java.lang.Runnable {
  private final int initMask;

  private final cats.effect.IO<A> startIO;

  private final scala.concurrent.ExecutionContext startEC;

  private final cats.effect.unsafe.IORuntime runtime;

  private cats.effect.ByteStack conts;

  private final cats.effect.ArrayStack<java.lang.Object> objectState;

  private scala.concurrent.ExecutionContext currentCtx;

  private cats.effect.ArrayStack<scala.concurrent.ExecutionContext> ctxs;

  private boolean canceled;

  private int masks;

  private boolean finalizing;

  private final int childMask;

...

After:

Compiled from "IOFiber.scala"
public final class cats.effect.IOFiber<A> extends cats.effect.IOFiberPlatform<A> implements cats.effect.kernel.Fiber<cats.effect.IO, java.lang.Throwable, A>, java.lang.Runnable {
  private final int initMask;

  private final cats.effect.unsafe.IORuntime runtime;

  private cats.effect.ByteStack conts;

  private final cats.effect.ArrayStack<java.lang.Object> objectState;

  private scala.concurrent.ExecutionContext currentCtx;

  private cats.effect.ArrayStack<scala.concurrent.ExecutionContext> ctxs;

  private boolean canceled;

  private int masks;

  private boolean finalizing;

  private final int childMask;

...

Then I figured, why not use it for autoCede as well. Here are the results.

Benchmark results (very marginal improvements, but this is to be expected):

Benchmark	series/3.x		error	unit	this PR		error	unit
AsyncBenchmark.async	16944.240	±	260.687	ops/s	17251.533	±	232.521	ops/s
AsyncBenchmark.race	21521.173	±	410.881	ops/s	21687.002	±	306.729	ops/s
AsyncBenchmark.racePair	20644.814	±	1180.355	ops/s	21109.900	±	1268.308	ops/s
AsyncBenchmark.start	5888.046	±	356.687	ops/s	5943.158	±	74.453	ops/s
DeepBindBenchmark.async	1313.741	±	76.735	ops/s	1389.603	±	33.490	ops/s
DeepBindBenchmark.delay	3128.832	±	112.297	ops/s	3175.600	±	131.373	ops/s
DeepBindBenchmark.pure	4164.669	±	116.216	ops/s	4184.599	±	112.218	ops/s
ShallowBindBenchmark.async	976.105	±	6.784	ops/s	979.814	±	16.856	ops/s
ShallowBindBenchmark.delay	2792.907	±	78.072	ops/s	2911.944	±	287.622	ops/s
ShallowBindBenchmark.pure	3115.989	±	30.956	ops/s	3528.893	±	102.307	ops/s

[djspiewak]

Wait… what? How? Doesn't this break down if you nest multiple evalOns?

[vasilmkd]

Each evalOn relinquishes the runloop immediately with execute(ec)(this), so the pushing to the objectState is immediately followed by a pop in evalOnR. It's the exact same logic.