https://searchfox.org/mozilla-central/rev/94c6b5f06d2464f6780a52f32e917d25ddc30d6b/js/src/jit/IonBuilder.cpp#13895-13898

One idea would be to compute the average/X-percentile/max/1.5x-max of the heap-increase across Ion compilation, and store it in a JSRuntime field.

When starting an Ion compilation we can check if adding this value would trigger a GC during the compilation or soon after it. Therefore preventing the compilation until the GC heap is compacted or the heap reserved size is enlarged.

We might as well trigger a GC if our compilation queue is already empty, when checking this GC threshold, as our compilation would be waiting for the GC to happen to do its Ion compilation.

(In reply to Olli Pettay [:smaug] from comment #0)

https://searchfox.org/mozilla-central/rev/94c6b5f06d2464f6780a52f32e917d25ddc30d6b/js/src/jit/IonBuilder.cpp#13895-13898

This nursery case should be rare in practice, but I think it's worth considering removing it. Instead of this we could either:

1. Deoptimize in IonBuilder when we see a nursery object.
2. Find a way to support nursery objects. For TypeSets and type constraints what might work is some sort of linked list or Vector we trace on the main thread and assert is never accessed off-thread.

The mechanism highlighted in Comment 1 has been removed; we seem to support some nursery stuff in the warp oracle.