1547565 - Atom pinning state is duplicated in AtomStateEntry and JSAtom flag

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task, P3)

Description

[Jon Coppeard (:jonco)]

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.

Comment 1

[Jon Coppeard (:jonco)]

(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.

Comment 2

[Jon Coppeard (:jonco)]

Attachment: Bug 1547565 - Remove AtomStateEntry and use ReadBarriered<JSAtom*> instead in the atoms table r=jandem?

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e85578d93db4
Remove AtomStateEntry and use ReadBarriered<JSAtom*> instead in the atoms table r=jandem

Comment 4

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/e85578d93db4

Comment 5

[Jon Coppeard (:jonco)]

(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.

Comment 6

[Jon Coppeard (:jonco)]

Backout:

https://hg.mozilla.org/integration/mozilla-inbound/rev/1e842a21a90ae2e4f9f94f523962c564ef4e1e18

Comment 7

[Julien Cristau [:jcristau]]

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

Comment 8

[Jon Coppeard (:jonco)]

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

Comment 9

[Jon Coppeard (:jonco)]

Attachment: backout-bug1547565-esr68

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/98e0742f8344