diff options
| author | haraken <haraken@chromium.org> | 2016-02-09 18:49:40 -0800 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2016-02-10 02:50:53 +0000 |
| commit | 485c63ccd15b1e6efe6baf67010da6ea2db94e0d (patch) | |
| tree | 4951991294934e7a9c0124774ecc313b6f97f943 /tools | |
| parent | 1619569f06985b5fdf11043b1f3ed844cbe256c1 (diff) | |
| download | chromium_src-485c63ccd15b1e6efe6baf67010da6ea2db94e0d.zip chromium_src-485c63ccd15b1e6efe6baf67010da6ea2db94e0d.tar.gz chromium_src-485c63ccd15b1e6efe6baf67010da6ea2db94e0d.tar.bz2 | |
Move hasPendingActivity from ActiveDOMObject to ScriptWrappable
Currently hasPendingActivity is a method of ActiveDOMObject (by accident),
so a lot of objects need to become ActiveDOMObject just to override hasPendingActivity.
This is not nice in terms of both design and performance.
- In terms of design, ActiveDOMObject is an object whose lifetime is tied
with ExecutionContext. On the other hand, hasPendingActivity is a mechanism to
keep alive a wrapper while the underlying DOM object has some pending activities.
These two are totally different notions.
- In terms of performance, ActiveDOMObjects are heavy because they must be observed
by LifecycleObservers and notified when the observing context changes its lifetime state.
It's not nice to increase the number of ActiveDOMObjects.
Given the above, this CL moves hasPendingActivity from ActiveDOMObject to ScriptWrappable.
The most tricky part is how to detect the fact that all pending activities of a worker are gone.
Before this CL, this was detected by scanning a list of ActiveDOMObjects and checking their
pending activities when the main thread posts a message to the worker. After this CL,
it is detected by scanning a list of ScriptWrappables and checking their pending activities.
Given that the number of ScriptWrappables is larger than the number of ActiveDOMObjects,
this CL will increase the overhead of scanning at every postMessage. I don't know how large
the overhead is, but I hope that the number of ScriptWrappables in workers is limited in
common cases and thus the overhead wouldn't be an issue.
This CL passes all tests in fast/workers, in particular the following tests:
- worker-messageport-gc.html (which checks that a worker that has a pending timer task doesn't get garbage-collected)
- dedicated-worker-lifecycle.html (which checks that a worker that doesn't have any pending activity is garbage-collected in a finite time period)
BUG=483722
TEST=fast/workers/
Review URL: https://codereview.chromium.org/1609343002
Cr-Commit-Position: refs/heads/master@{#374584}
Diffstat (limited to 'tools')
| -rw-r--r-- | tools/metrics/histograms/histograms.xml | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml index 77b2272..0c0c308 100644 --- a/tools/metrics/histograms/histograms.xml +++ b/tools/metrics/histograms/histograms.xml @@ -3193,6 +3193,14 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries. </summary> </histogram> +<histogram name="Blink.ScanPendingActivityDuration" units="ms"> + <owner>haraken@chromium.org</owner> + <summary> + Duration of time taken to scan pending activities of all V8 wrappers in a + worker thread. + </summary> +</histogram> + <histogram name="Blink.XHR.setRequestHeader.HeaderValueCategoryInRFC7230" enum="XMLHttpRequestHeaderValueCategoryInRFC7230"> <owner>hiroshige@chromium.org</owner> |