Closed Bug 981554 Opened 6 years ago Closed 6 years ago

Move allocator for optimized Baseline stubs from JitCompartment to JitZone

Categories

(Core :: JavaScript Engine: JIT, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: jandem, Assigned: jandem)

References

Details

Attachments

(1 file)

Every compartment with Baseline code has a LifoAlloc (with 4K default chunk size) for optimized stubs.

Although this allocator is purged on every code-discarding-GC, it'd be nice to move it from compartment to zone (as every allocator will have a chunk with some unused space, and there's also the size of the LifoAlloc itself).
Attached patch PatchSplinter Review
This patch adds JitZone (like JitCompartment and JitRuntime), and moves the allocator to it.

~AutoDebugModeInvalidation only discards JIT code for some compartments, so we can no longer free the LifoAlloc there, but that should be okay as long as Zone::discardJitCode does this.

There's probably more stuff in JitCompartment that we can move to JitZone; I'll look into it.
Attachment #8388474 - Flags: review?(n.nethercote)
Comment on attachment 8388474 [details] [diff] [review]
Patch

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

Looks good.

::: js/src/gc/Zone.h
@@ +18,5 @@
>  
>  namespace js {
>  
> +namespace jit {
> +    class JitZone;

Nit: I think we usually don't indent this case.

::: js/xpconnect/src/XPCJSRuntime.cpp
@@ +2076,5 @@
>      ZCREPORT_BYTES(cJSPathPrefix + NS_LITERAL_CSTRING("baseline/data"),
>          cStats.baselineData,
>          "The Baseline JIT's compilation data (BaselineScripts).");
>  
> +    ZCREPORT_BYTES(cJSPathPrefix + NS_LITERAL_CSTRING("baseline/fallback-stubs"),

Is there a reason you moved the optimized stubs but kept the fallback stubs?
Attachment #8388474 - Flags: review?(n.nethercote) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/4197edad59d6

(In reply to Nicholas Nethercote [:njn] from comment #2)
> Is there a reason you moved the optimized stubs but kept the fallback stubs?

The fallback stubs are allocated per BaselineScript, so we can't move them as easily.

We could add a per-Zone allocator for them (would be more memory-efficient), but then we can only purge it when there's no Baseline code for this Zone on the stack, so I'm not sure if that's better.
Oh and this was green on Linux x64 a few days ago:

https://tbpl.mozilla.org/?tree=Try&rev=7b3254153f6e
https://hg.mozilla.org/mozilla-central/rev/4197edad59d6
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.