Open Bug 1930281 Opened 13 days ago Updated 9 hours ago

Remove JSContext usage from baseline compiler

Categories

(Core :: JavaScript Engine: JIT, task, P1)

task

Tracking

()

People

(Reporter: iain, Assigned: iain)

References

(Blocks 2 open bugs)

Details

(Keywords: leave-open)

Attachments

(13 files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

As a prerequisite for offthread baseline compilation, we have to remove all uses of JSContext from the parts of the baseline compiler that we intend to run offthread.

I originally wrote this patch thinking that it would let us call MaybeOptimizeBindGlobalName offthread. In retrospect that obviously doesn't work, since it involves accessing global properties, but removing the rooting still seems worth landing now that I've written the patch.

Keywords: leave-open
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9dc5524dd997 Use CompileRuntime in BaselineCodegen r=jandem https://hg.mozilla.org/integration/autoland/rev/75af582dff0a Remove unnecessary rooting from MaybeOptimizeBindGlobalName r=jandem

Eventually I think this data should move to some sort of BaselineSnapshot struct, but for now I'm just putting it in the handler.

Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4b1ed4ac7afa Move IonCompileable checks out of constructor r=jandem https://hg.mozilla.org/integration/autoland/rev/31ca9b2fa3a5 Don't pass JSContext to handler r=jandem https://hg.mozilla.org/integration/autoland/rev/9c0e67cd9404 Refactor some error handling r=jandem https://hg.mozilla.org/integration/autoland/rev/6a25a61d5216 Store globals in baseline compiler r=jandem https://hg.mozilla.org/integration/autoland/rev/e9af2693fdfe Generate DebugTrapHandler earlier r=jandem
Depends on: 1838554
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/85ffdbd82112 Allow BaselinePerfSpewer::recordInstruction to be used off-thread r=jandem https://hg.mozilla.org/integration/autoland/rev/864a95c0cbf8 Hoist OOM reporting outward r=jandem https://hg.mozilla.org/integration/autoland/rev/159e5286ec2a Refactor compilerWarmUpThreshold r=jandem https://hg.mozilla.org/integration/autoland/rev/bf9fe518cd1a Remove cx field from BaselineCodeGen r=jandem

StackMacroAssembler can only be stack-allocated on the main thread, so we need to be able to use a different MacroAssembler that can enforce GC safety off-thread (similarly to IonHeapMacroAssembler).

I wanted to put a StackMacroAssembler as a member of BaselineInterpreterGenerator, to avoid having to allocate one at the call site. However, it was uninitialized in the BaselineCodeGen construtor, because derived class fields are initialized after calling the superclass constructor.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: