Consider moving Baseline fallback IC stub code to JSRuntime

RESOLVED FIXED in Firefox 68

Status

()

enhancement
P3
normal
RESOLVED FIXED
8 months ago
3 months ago

People

(Reporter: tcampbell, Assigned: jandem)

Tracking

(Blocks 2 bugs)

unspecified
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(1 attachment)

Reporter

Description

8 months ago
As we complete the migration of ICs to CacheIR, the remaining ICs are primarily fallbacks. We should investigate moving this JitCode to the JSRuntime to be shared.

This would simplify parts of baseline compilation and we may be able to eliminate the fallback IC stub space.
Reporter

Updated

8 months ago
Depends on: 1501316
Assignee

Updated

8 months ago
Assignee

Comment 1

8 months ago
Let's do this after bug 1499644 lands to avoid bitrotting that (and this patch will look nicer on top of that).
Depends on: 1499644
Assignee

Comment 2

7 months ago
I've been thinking a bit about the right design for this.

* We probably need a FallbackStubKind enum class so we can store an EnumeratedArray<FallbackStubKind, uint32_t> in JitRuntime - storing the offset in a shared JitCode* instance, similar to (other) runtime trampolines.

* The stub compiler class for each stub is currently responsible for (1) Compiling stub code and (2) allocating the stub.

For (1) I think it might be nice to use a shared FallbackStubCompiler class that compiles all the fallback stub codes. It could call a static method on each fallback stub class to compile the code for it, for example we would have:

  static void emitCode(FallbackStubCompiler& compiler);

on ICTypeOf_Fallback, ICGetProp_Fallback, etc.

For (2) I think we can probably allocate the stub directly in ICScript::Create, once bug 1499644 is done. Maybe with some helper lambda and perfect forwarding.
Assignee

Comment 3

3 months ago

I started working on this as first step to speed up ICScript allocation.

Having this in JitRealm instead of JitRuntime is just wasteful and after this and Ian's work converting the Call IC to CacheIR we should be able to remove a lot of the old ICStubCompiler infrastructure.

Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Assignee

Comment 4

3 months ago

Fallback code is now generated (as a single JitCode instance) when we create the
JitRuntime.

In ICScript::Create we can now allocate the fallback stubs directly (we no
longer need a Compiler class for each fallback stub) because we no longer have
to handle the compile-code case.

Assignee

Updated

3 months ago
Blocks: 1537906

Comment 5

3 months ago
Pushed by jdemooij@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d6fb444fa553
Move Baseline IC fallback code from JitRealm to JitRuntime. r=tcampbell

Comment 6

3 months ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.