Created attachment 758674 [details] [diff] [review] v0 JIT code implicitly bakes the enable/disable status of the nursery into its allocators, so continuing to run existing JIT code after disabling continues to allocate into the disabled nursery. Fortunately, we only disable the nursery when we exceed gcMaxBytes and when we enter post-barrier verification. Because both of these features are only available when testing and fuzzing, the performance of Nursery::disable does not matter at all. Thus, the simple solution of just purging and re-generating the JIT code is adequate in this case.
It seems a little unfortunate to purge jitcode every time we verify post barriers? How does jitcode bake in the enabled/disabled status? Since the nursery is resizable jitcode won't bake in the end pointer, and will load it when doing allocations. If the position >= end when the nursery is disabled then jitcode should always take a slow path when allocating and go through the tenured heap.
Comment on attachment 758674 [details] [diff] [review] v0 Hmm, okay. I assumed that since you wanted bug 877835 to disable by updating numAvailableChunks_ rather than position_ that you preferred this approach.
If numAvailableChunks_ is zero then the end pointer (which is dynamically loaded by jitcode when allocating from the nursery) should never be > either the start or current position in the nursery.
Created attachment 758844 [details] [diff] [review] v1 That works well, thanks.