Atom pinning state is duplicated in AtomStateEntry and JSAtom flag

RESOLVED FIXED in Firefox 68

Status

()

task
P3
normal
RESOLVED FIXED
3 months ago
10 days ago

People

(Reporter: jonco, Assigned: jonco)

Tracking

unspecified
mozilla68
Points:
---

Firefox Tracking Flags

(firefox-esr6869+ disabled, firefox68 fixed, firefox69+ disabled)

Details

Attachments

(1 attachment, 1 obsolete attachment)

The pinning state in AtomStateEntry is redundant. We should be able to remove this and use JSAtom* in the atoms table.

This class does perform a barrier, but there's only one place where it fires. We can just execute the barrier explicitly in this case.

Assignee: nobody → jcoppeard
Priority: -- → P3

(In reply to Jon Coppeard (:jonco) from comment #0)
I think I'll go with ReadBarriered<JSAtom*> instead of the raw pointer for documentation purposes.

Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e85578d93db4
Remove AtomStateEntry and use ReadBarriered<JSAtom*> instead in the atoms table r=jandem
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

(In reply to Jon Coppeard (:jonco) from comment #0)
In the description I complained that:

The pinning state in AtomStateEntry is redundant

But then I found my own comment as to why we have this redundant state in bug 1445196:

This keeps the state in the atoms table entry as well so it doesn't require touching all the atoms during marking, but I'm not sure how important this is. I'm a bit wary of doing anything that could affect marking speed because the atoms table can be pretty large.

Looking at telemetry, there was a jump from ~2% to ~6% in the GC_SLOW_PHASE telemetry for the phase where this happens (MARK_RUNTIME_DATA) when this change landed. Also there was an unexplained jump in GC_MARK_ROOTS_MS a few days after this, although the way that histogram is set up means the data is not accurate.

I think I'm going to back this out and add a comment as to why we duplicate this state.

There's also a crash associated with this change but I think that's just because we're touching more memory so it's more likely to crash on heap corruption.

Attachment #9061322 - Attachment is obsolete: true

This landed in 68, and the backout in 69. Should we do something about the perf hit from this in 68 ESR?

Flags: needinfo?(jcoppeard)

(In reply to Julien Cristau [:jcristau] from comment #7)
Might be as well to. I'll make a patch.

Flags: needinfo?(jcoppeard)

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Patch to back this bug out of esr68 for perf regression.
  • User impact if declined: Perf regression, although probably fairly minor.
  • Fix Landed on Version: 69
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch reverts to the previous state. The backout has been on central for a week with no issues.
  • String or UUID changes made by this patch: None
Attachment #9076166 - Flags: approval-mozilla-esr68?
Comment on attachment 9076166 [details] [diff] [review]
backout-bug1547565-esr68

Fixes a perf regression in 68 which was already backed out in 69. Approved for 68.1esr for consistency.
Attachment #9076166 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
You need to log in before you can comment on or make changes to this bug.