879874 - GC: purge jitcode when we disable the nursery

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Terrence Cole [:terrence]]

Attachment: 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.

Comment 1

[Brian Hackett [Laid off!]]

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 2

[Terrence Cole [:terrence]]

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.

Comment 3

[Brian Hackett [Laid off!]]

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.

Comment 4

[Terrence Cole [:terrence]]

Attachment: v1

That works well, thanks.

Comment 5

[Terrence Cole [:terrence]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/61a183d6b59e

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/61a183d6b59e