Closed Bug 1669481 Opened 5 years ago Closed 5 years ago

Stop updating DOMExpandoGeneration IC stub fields

Categories

(Core :: JavaScript Engine: JIT, task, P3)

task

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox83 --- fixed

People

(Reporter: jandem, Assigned: jandem)

References

Details

Attachments

(3 files)

We have an optimization to update existing Baseline/Ion IC stubs if only the DOMExpandoGenerationField field changed. Unfortunately this complicates Warp transpiler support for these DOM proxies (see bug 1668831) and we don't do this for any other IC stubs.

evilpie added some logging and we almost never update stubs on popular websites and speedometer. There's also some risk of updating the same stub repeatedly in pathological cases and that could be worse than not updating at all.

Updating stubs complicates Warp transpiler support for DOM proxies and doesn't
actually show up much on websites.

The Ion CacheIR implementation can now bake in the generation again instead of
loading it from the stub.

Depends on D92608

When looking at the old patch in bug 1329195 I also noticed this change: https://hg.mozilla.org/mozilla-central/rev/80e4fe7ff7cb#l5.37 Not sure if that should be reverted as well.

Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d9ca15f17655 part 1 - Stop updating IC stubs for DOMExpandoGeneration changes. r=evilpie https://hg.mozilla.org/integration/autoland/rev/ca23b81385d4 part 2 - Change DOMExpandoGeneration stub field to RawInt64. r=evilpie https://hg.mozilla.org/integration/autoland/rev/48b632dabf39 part 3 - Remove IonCacheIRCompiler::stub_. r=evilpie
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: