Closed
Bug 1365069
Opened 7 years ago
Closed 7 years ago
Baldr: avoid wasm::Compartment::lookupCode on warm paths
Categories
(Core :: JavaScript Engine, enhancement)
Core
JavaScript Engine
Tracking
()
RESOLVED
DUPLICATE
of bug 1277562
People
(Reporter: luke, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
7.34 KB,
patch
|
Details | Diff | Splinter Review |
Assuming bug 1359027 adds a lock to lookupCode, it'd be nice to avoid calling this super-often. After bug 1334504, we can now find a frame's code simply by fp->tls->instance->code so many of these uses of lookupCode() are now unnecessary.
Attachment #8867906 -
Flags: review?(lhansen)
Comment 1•7 years ago
|
||
Comment on attachment 8867906 [details] [diff] [review] lookup-code-less Review of attachment 8867906 [details] [diff] [review]: ----------------------------------------------------------------- Generally this seems fine, but if I hesitate it is because the assertion in the patch comment is not (or will not be) correct, you *cannot* "find a frame's code simply by fp->tls->instance->code", because that instance does not have a code hanging off it, it has something that has potentially two Code objects, one per tier. Really, it is a lookup-by-pc operation on instance->code that yields (or will yield) "the" Code for the frame. I wonder if we can delay this until after bug 1334504, at least, so that we have a better idea about what the data structures might look like and what kind of locking we might need.
Comment 2•7 years ago
|
||
Of course I meant to write that we should delay until after bug 1359027.
Reporter | ||
Comment 3•7 years ago
|
||
Sure, happy to hold off for bug 1334504. Mostly, I just wanted to convince myself that we wouldn't be adding a locked lookup to any warmish paths like profiling's stack-walking. FWIW, I think with tiering the tweak to this patch would be that you'd write fp->tls->instance->code(pc), passing the 'pc' so the instance could do lock-free query of whether pc was in each of its codes. (Lock free b/c even if a tier can be added asynchronously, as long as each tier is stored in an Atomic, the pc you have is for a halted thread so the tier containing pc will definitely be set.)
Reporter | ||
Updated•7 years ago
|
Attachment #8867906 -
Flags: review?(lhansen)
Comment 4•7 years ago
|
||
(In reply to Luke Wagner [:luke] from comment #3) > FWIW, I think with tiering the tweak to this patch would be that you'd write > fp->tls->instance->code(pc), passing the 'pc' so the instance could do > lock-free query of whether pc was in each of its codes. (Lock free b/c even > if a tier can be added asynchronously, as long as each tier is stored in an > Atomic, the pc you have is for a halted thread so the tier containing pc > will definitely be set.) Yup, makes sense.
Comment 5•7 years ago
|
||
(In reply to Lars T Hansen [:lth] from comment #4) > (In reply to Luke Wagner [:luke] from comment #3) > > > FWIW, I think with tiering the tweak to this patch would be that you'd write > > fp->tls->instance->code(pc), passing the 'pc' so the instance could do > > lock-free query of whether pc was in each of its codes. (Lock free b/c even > > if a tier can be added asynchronously, as long as each tier is stored in an > > Atomic, the pc you have is for a halted thread so the tier containing pc > > will definitely be set.) > > Yup, makes sense. Indeed the patch I just uploaded to bug 1277562 contains several such accessors on Code.
Reporter | ||
Comment 6•7 years ago
|
||
(Want me to rebase, r? and land this independently or will you fold this into your patch stack?)
Comment 8•7 years ago
|
||
Rebased to sit on top of the patch queue in bug 1277562. Will ask for review on this one as soon as the patches on that one are approved.
Attachment #8867906 -
Attachment is obsolete: true
Updated•7 years ago
|
Comment 9•7 years ago
|
||
Patch being merged into 1277562 and landed with that.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Updated•3 years ago
|
Assignee: lhansen → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•