Normally the ionLazyLink list shouldn't be long. Or the compiled functions get used or thrown away since the script is gone. Now it is possible to create a function execute it a few times to get it compiled, but not long enough so we can link it. In that case we keep the IonBuilder available, which takes some space. Normal execution almost always links directly, but for this edge case it might be good to put a cap on it. I tested octane which needed at max 20 lazy link items. As a result took 100 which should give us some more leeway. This caps it at less than 100mb (very imprecise) in regress-476427.js. Before it would go to 2gb (and having 10000 items).

Comment on attachment 8748641 [details] [diff] [review] Patch Review of attachment 8748641 [details] [diff] [review]: ----------------------------------------------------------------- Good find! ::: js/src/vm/HelperThreads.cpp @@ +626,5 @@ > GlobalHelperThreadState::GlobalHelperThreadState() > : cpuCount(0), > threadCount(0), > threads(nullptr), > + ionLazyLinkListSize_(0), In GlobalHelperThreadState::finish we call ionLazyLinkList_.clear(). Can we reset this value to 0 there? @@ +734,5 @@ > +void > +GlobalHelperThreadState::ionLazyLinkListRemove(jit::IonBuilder* builder) > +{ > + builder->removeFrom(HelperThreadState().ionLazyLinkList()); > + ionLazyLinkListSize_--; Nit: MOZ_ASSERT(ionLazyLinkListSize_ > 0); before this. To be even more sure we keep them in sync, we can also add something like: MOZ_ASSERT(HelperThreadState().ionLazyLinkList().empty() == (ionLazyLinkListSize_ == 0));