Closed Bug 1507066 Opened Last year Closed Last year

Move the bytecode typemap from BaselineScript to TypeScript

Categories

(Core :: JavaScript Engine, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla66
Tracking Status
firefox66 --- fixed

People

(Reporter: jandem, Assigned: jandem)

References

Details

Attachments

(4 files)

After bug 1499644 all Baseline ICs should work fine without a BaselineScript, except for the type monitoring code because that requires the map stored in BaselineScript.

We should just move that map from BaselineScript to TypeScript. We could even combine it with the bytecode iteration in ICScript::Create (TypeScript always has an ICScript after bug 1499644) so we don't need a second pass for this.

(Maybe we can move JSScript::nTypeSets_ from JSScript to TypeScript at the same time and remove the code for computing that in the frontend.)
Priority: -- → P3
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED

We need this for the interpreter so our Baseline ICs work without a BaselineScript.
Also these days TypeScript is a more logical place for it anyway.

This also cleans up the TypeScript allocation code to stop relying on zero
initialization (malloc instead of calloc) and we now use the constructor.

This makes it a bit clearer that it's just the JOF_TYPESET TypeSets and does not
include the arguments/this types.

Depends on D17228

Pushed by jdemooij@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f745bbf9f347
part 1 - Move bytecode map from BaselineScript to TypeScript. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/ec1aa436aeff
part 2 - Rename JSScript::nTypeSets to JSScript::numBytecodeTypeSets. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/ddf227b9fa75
part 3 - Move the bytecodeTypeMap hint to TypeScript. r=tcampbell
https://hg.mozilla.org/integration/autoland/rev/686e61adb628
part 4 - Simplify the bytecodeTypeMap binary search code. r=tcampbell
You need to log in before you can comment on or make changes to this bug.