All users were logged out of Bugzilla on October 13th, 2018

NewRunnable & friends could offer run-once optimizations

NEW
Unassigned

Status

()

P3
normal
2 years ago
a year ago

People

(Reporter: gerald, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
In a lot of cases, runnables will only ever be run once, e.g.: when created and immediately dispatched to a thread or task queue.

With these, the default storage&passing strategy involves storing a copy, and passing it to the target function by const-reference (assuming bug 1318228 lands).
This makes sense if the runnable could be called again, as we want to provide access to the same copy.
But if the runnable can only run once, we could instead move() from the stored copy, with all the potential optimization benefits of move semantics.

I am unsure of how to go about this exactly; possibly a new range of functions with names like NewRunnableOnceMethod, or a struct-tag that could be added to existing functions?
(Reporter)

Comment 1

2 years ago
As a quick exercise today, I added a run-counter in RunnableMethodImpl, and `MOZ_ASSERT(mRun <= 1 || sizeof...(Storages) == 0);` in the destructor, and didn't get any assertions.
This is a good sign that parameter storage could "just" be optimized with move semantics where possible. But it may still be dangerous, in case someone doesn't know that and starts recycling runnables.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5181997dd6b9d13c317d6dd582124f95714bbc45

Note: The 'sizeof...(Storages) == 0' was needed because there are runnables that *are* re-run in netwerk/cache2, but fortunately they are all parameter-less. Look for: https://dxr.mozilla.org/mozilla-central/search?q=YieldAndRerun
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.