HTML job queue integration

[littledan]

If WeakRef finalizers should only be implicitly run after the PromiseJob queue is flushed, this property should encoded in HTML's job queue, which is different from JavaScript's, see tc39/ecma262#735 . Otherwise, if they are another kind of microtask queue item interspersed with Promise reactions, make sure it's either in the PromiseJob queue (which HTML requires) or that HTML has the appropriate adjustments to handle some other queue.

[littledan]

Thinking about this a bit more, I don't think it's a good idea to do this either in a microtask queue item (as @gsathya proposed) or at the microtask checkpoint (as the spec text that I wrote does), for two reasons:

• @domenic pointed out to me that the microtask checkpoint is a weird time to run this kind of code, as it could trigger more things to become dead, which would then wait for the next time around. In general, it's unfortunate to use the microtask checkpoint, as everyone will want to be the "last-est".
• More significantly, if JavaScript execution is idle for a time, then this may be a good time to perform extra garbage collection work, triggering finalizers to be scheduled. Once these finalizers run, it will free up the holdings (and unregister token) values, which may allow garbage collection to free more. If engines had to wait until something else triggered JavaScript execution, then this memory could be forced to be held live longer than needed, increasing memory usage.

For these reasons, I'd suggest that, when there is finalization work to do, we queue a task (on a new task source) to call the DoAgentFinalization abstract operation. I'm pretty optimistic that this won't be bad performance-wise, as there would be just one task for all the finalization in the whole agent. It would, however, require some more work in binding JavaScript engines to their host environments in implementations.

Thoughts? @gsathya @tschneidereit @marjakh

[littledan]

Event loop integration is specified in whatwg/html#4571 .