Closed Bug 1266887 Opened 4 years ago Closed 4 years ago

Move Rooted to the Zone

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox48 --- affected
firefox49 --- fixed

People

(Reporter: terrence, Assigned: terrence)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

We're well on our way to removing JSContext and I'd like to get Rooted off of it before it becomes a blocker. Rather than moving everything to the runtime and making it even more of a global, I'd prefer to move Rooted to the Zone. In theory, Rooted should not cross zones (at least not often), so this could lead to a nice assertion. And eventually we should even be able to take advantage of this to do faster root marking during Compartmental GC's.

I was not able to see any performance difference on octane, so I think the extra indirection will not be troublesome.
Attachment #8744514 - Flags: review?(sphink)
Comment on attachment 8744514 [details] [diff] [review]
6.2_move_rooted_to_zones-v0.diff

Hold on a tick. I didn't count on just how amazingly crazy the browser is during initialization.
Attachment #8744514 - Flags: review?(sphink)
Actually, it's trivial to check the zone first and root on the runtime or zone as needed. This should make it much easier to assert that everything lands in the right zone eventually.
Attachment #8745034 - Flags: review?(sphink)
Comment on attachment 8745034 [details] [diff] [review]
6.2v1_move_rooted_to_zones-v1.diff

Review of attachment 8745034 [details] [diff] [review]:
-----------------------------------------------------------------

I can't think of what could go wrong with this, which probably just means I'm having a failure of imagination.

::: js/src/gc/RootMarking.cpp
@@ +79,5 @@
>          trc, stackRoots_[JS::RootKind::Traceable], "Traceable");
>  }
>  
>  static void
>  MarkExactStackRoots(JSRuntime* rt, JSTracer* trc)

Someday, we probably ought to remove the "Exact" part of this name.

::: js/src/vm/Symbol.cpp
@@ +36,5 @@
>  
>  Symbol*
>  Symbol::new_(ExclusiveContext* cx, JS::SymbolCode code, JSString* description)
>  {
> +    JSAtom* atom = nullptr;

Is this change part of this bug?
Attachment #8745034 - Flags: review?(sphink) → review+
Comment on attachment 8745034 [details] [diff] [review]
6.2v1_move_rooted_to_zones-v1.diff

Review of attachment 8745034 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/vm/Symbol.cpp
@@ +36,5 @@
>  
>  Symbol*
>  Symbol::new_(ExclusiveContext* cx, JS::SymbolCode code, JSString* description)
>  {
> +    JSAtom* atom = nullptr;

Oddly, yes. We create the well-known symbols outside of any compartment, so my initial pass that did not have the JSRuntime fallback needed a different way to handle this case. Turns out we don't even need the Rooted here; probably was from back when Atomized used to GC. I rolled the cases back, but it seemed silly to re-add the unnecessary root.
https://hg.mozilla.org/mozilla-central/rev/edb632ad80c4
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Depends on: 1269796
Looks like we're not going to be able to land this improvement until we actually land the context removal as well.
Resolution: FIXED → WONTFIX
Actually, we found that tspaint does not sync against GC, so this may be spurious.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
It may be spurious, or it may be (1) an issue with memory layout, although fairly unlikely, or (2) changed inlining, given MSVC's egregiously stupid heuristics in this area.

I think I'd like to re-land, cutting out the parts of RootLists that are not necessary on Zone to reduce the potential memory impacts and with |inline| sprinkled around all the potentially hot code. Given that this code is already hot on JSContext, I think anything remaining must be spurious.
https://hg.mozilla.org/mozilla-central/rev/113aed339ad2
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Depends on: 1274593
Depends on: 1306827
Blocks: 1306829
Depends on: 1334446
You need to log in before you can comment on or make changes to this bug.