Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2592403002:
[heap] Ensure progress when incrementally marking wrappers (Closed)
|
Created:
4 years ago by Michael Lippautz Modified:
4 years ago Reviewers:
ulan CC:
v8-reviews_googlegroups.com, Hannes Payer (out of office), ulan, haraken Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
Description[heap] Ensure progress when incrementally marking wrappers
The problem here is estimating the marking step size for wrapper tracing. If the
steps are too small, we cannot keep up with the mutator creating new wrappers.
The result is an endless stream of incremental marking steps, alternating v8 and
wrappers tracing, without ever finalizing in a GC.
The mitigation here is to abort finding the fix point after 10 incremental
iterations.
A proper solution would track newly created wrappers on the blink side during
wrapper tracing. Will give this more thought after the holidays.
BUG=chromium:668164, chromium:468240
Review-Url: https://codereview.chromium.org/2592403002
Cr-Commit-Position: refs/heads/master@{#41923}
Committed: https://chromium.googlesource.com/v8/v8/+/a47417b89373c615f9256800cfc803d84ba58378
Patch Set 1 #Patch Set 2 : Force marking in final pause #Patch Set 3 : Remove max iterations to 10 #
Messages
Total messages: 26 (21 generated)
Patchset #1 (id:1) has been deleted
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers BUG= ========== to ========== [heap] Ensure progress when incrementally marking wrappers BUG= ==========
mlippautz@chromium.org changed reviewers: + ulan@chromium.org
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers BUG= ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps without finalization. The mitigation here is to abort finding the fixpoint after 10 iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ==========
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps without finalization. The mitigation here is to abort finding the fixpoint after 10 iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps without finalization. The mitigation here is to abort finding the fixpoint after 10 iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ==========
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps without finalization. The mitigation here is to abort finding the fixpoint after 10 iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fixpoint after 10 iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ==========
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fixpoint after 10 iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fixpoint after 10 incremental iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ==========
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fixpoint after 10 incremental iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fix point after 10 incremental iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ==========
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fix point after 10 incremental iterations. A proper solution would track new wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fix point after 10 incremental iterations. A proper solution would track newly created wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ==========
haraken: fyi; will give this more thought after the holidays but want to get the remaining broken bots green
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by mlippautz@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from ulan@chromium.org Link to the patchset: https://codereview.chromium.org/2592403002/#ps60001 (title: "Remove max iterations to 10")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 60001, "attempt_start_ts": 1482418115478510,
"parent_rev": "8435cc852672c504d5899cc2765c5b895e658efe", "commit_rev":
"a47417b89373c615f9256800cfc803d84ba58378"}
Message was sent while issue was closed.
Description was changed from ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fix point after 10 incremental iterations. A proper solution would track newly created wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 ========== to ========== [heap] Ensure progress when incrementally marking wrappers The problem here is estimating the marking step size for wrapper tracing. If the steps are too small, we cannot keep up with the mutator creating new wrappers. The result is an endless stream of incremental marking steps, alternating v8 and wrappers tracing, without ever finalizing in a GC. The mitigation here is to abort finding the fix point after 10 incremental iterations. A proper solution would track newly created wrappers on the blink side during wrapper tracing. Will give this more thought after the holidays. BUG=chromium:668164, chromium:468240 Review-Url: https://codereview.chromium.org/2592403002 Cr-Commit-Position: refs/heads/master@{#41923} Committed: https://chromium.googlesource.com/v8/v8/+/a47417b89373c615f9256800cfc803d84ba... ==========
Message was sent while issue was closed.
Committed patchset #3 (id:60001) as https://chromium.googlesource.com/v8/v8/+/a47417b89373c615f9256800cfc803d84ba...
Message was sent while issue was closed.
A revert of this CL (patchset #3 id:60001) has been created in https://codereview.chromium.org/2602433002/ by mlippautz@chromium.org. The reason for reverting is: This won't work because the finalization still checks whether both marking deques are empty, also calling into blink. So we never proceed there.. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
