Remove JSContext usage from baseline compiler
Categories
(Core :: JavaScript Engine: JIT, task, P1)
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.
Assignee | ||
Comment 1•13 days ago
|
||
Assignee | ||
Comment 2•13 days ago
|
||
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.
Assignee | ||
Updated•7 days ago
|
Comment 4•7 days ago
|
||
bugherder |
Assignee | ||
Comment 5•6 days ago
|
||
Assignee | ||
Comment 6•6 days ago
|
||
Assignee | ||
Comment 7•6 days ago
|
||
Assignee | ||
Comment 8•6 days ago
|
||
Eventually I think this data should move to some sort of BaselineSnapshot struct, but for now I'm just putting it in the handler.
Assignee | ||
Comment 9•6 days ago
|
||
Comment 10•4 days ago
|
||
Assignee | ||
Comment 11•3 days ago
|
||
Assignee | ||
Comment 12•3 days ago
|
||
Assignee | ||
Comment 13•3 days ago
|
||
Assignee | ||
Comment 14•3 days ago
|
||
Comment 15•3 days ago
|
||
bugherder |
Comment 16•2 days ago
|
||
Comment 17•2 days ago
|
||
bugherder |
Assignee | ||
Comment 18•9 hours ago
|
||
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.
Assignee | ||
Comment 19•9 hours ago
|
||
Description
•