|
|
Created:
4 years, 4 months ago by yhirano Modified:
4 years, 4 months ago Reviewers:
haraken CC:
chromium-reviews, blink-reviews, loading-reviews_chromium.org, tyoshino+watch_chromium.org, Nate Chapin, gavinp+loader_chromium.org, hiroshige Base URL:
https://chromium.googlesource.com/chromium/src.git@onheap-threadable-loader Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionMove ThreadableLoader to Oilpan heap (3/3)
This CL is a refactoring and does not change the behavior.
BUG=587663
Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8
Committed: https://crrev.com/3a06b506b18754545e5b50bf66d839c8b152f695
Cr-Original-Commit-Position: refs/heads/master@{#409961}
Cr-Commit-Position: refs/heads/master@{#411919}
Patch Set 1 #Patch Set 2 : fix #Patch Set 3 : fix #
Total comments: 7
Patch Set 4 : rebase #Patch Set 5 : fix #Patch Set 6 : rebase #Patch Set 7 : rebase #Patch Set 8 : revert DocumentThreadableLoader changes #
Depends on Patchset: Dependent Patchsets: Messages
Total messages: 55 (40 generated)
The CQ bit was checked by yhirano@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 checked by yhirano@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 ========== Move ThreadableLoader to Oilpan heap (2/2) This CL is a refactoring and does not change the behavior. BUG=587663 ========== to ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 ==========
yhirano@chromium.org changed reviewers: + haraken@chromium.org
The CQ bit was checked by yhirano@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 https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (left): https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:57: class CORE_EXPORT DocumentThreadableLoader final : public ThreadableLoader, private RawResourceClient { I'm just curious but is there any reason for the private inheritance? https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h (right): https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:60: // ResourceLoader work only in the main thread, A WorkerThreadableLoader holds A => a https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:76: // +-----------------------+ CTWP +----------------------+-+ I asked this question before but let me confirm again: What happens if we use CTP for the WorkerThreadableLoader => MainThreadLoaderHolder? It will create a cycle temporarily but the cycle is explicitly broken when the worker thread dies. So it won't cause memory leaks, right? https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:81: // +------------------+ This model looks amazing! It looks much simpler than before.
The CQ bit was checked by yhirano@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.
The CQ bit was checked by yhirano@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...
https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (left): https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:57: class CORE_EXPORT DocumentThreadableLoader final : public ThreadableLoader, private RawResourceClient { On 2016/07/29 15:00:44, haraken wrote: > > I'm just curious but is there any reason for the private inheritance? I don't know, and I don't like private inheritance, but I imagine that the original author didn't want to allow an external user to handle DocumentThreadableLoader as RawResourceClient / ResourceOwner. https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h (right): https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:60: // ResourceLoader work only in the main thread, A WorkerThreadableLoader holds On 2016/07/29 15:00:44, haraken wrote: > > A => a Done. https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:76: // +-----------------------+ CTWP +----------------------+-+ On 2016/07/29 15:00:44, haraken wrote: > > I asked this question before but let me confirm again: What happens if we use > CTP for the WorkerThreadableLoader => MainThreadLoaderHolder? It will create a > cycle temporarily but the cycle is explicitly broken when the worker thread > dies. So it won't cause memory leaks, right? > > It's a bit more complicated. 1. As WorkerThreadableLoader requires users to cancel it appropriately (see ThreadableLoader's comments), WorkerThreadableLoader <=> MainThreadableLoaderHelper persistent loop should be no harm (though I don't feel good with the loop). 2. It is not planned now, but I think it's good to move ThreadableLoaderClient to the heap. With on-heap ThreadableLoaderClient, WorkerThreadableLoader => ThreadableLoaderClient "raw ptr" will be replaced with a Member ptr. Also, it's very common that a ThreadableLoaderClient has a ThreadableLoader as Member. That means there will be a persistent loop from ThreadableLoaderClient to ThreadableLoaderClient itself. That's problematic. Assume that a ThreadableLoader has a pre-finalizer that cancels its ThreadableLoader. That pre-finalizer will not be called because there is a persistent loop. 3. As you say that loop will be broken when the thread is terminated but I think that's not enough. We still see unbound memory consumption increase in a long-running worker thread.
On 2016/08/01 08:52:38, yhirano wrote: > https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h (left): > > https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h:57: class > CORE_EXPORT DocumentThreadableLoader final : public ThreadableLoader, private > RawResourceClient { > On 2016/07/29 15:00:44, haraken wrote: > > > > I'm just curious but is there any reason for the private inheritance? > > I don't know, and I don't like private inheritance, but I imagine that the > original author didn't want to allow an external user to handle > DocumentThreadableLoader as RawResourceClient / ResourceOwner. > > https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h (right): > > https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:60: // > ResourceLoader work only in the main thread, A WorkerThreadableLoader holds > On 2016/07/29 15:00:44, haraken wrote: > > > > A => a > > Done. > > https://codereview.chromium.org/2193683004/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/loader/WorkerThreadableLoader.h:76: // > +-----------------------+ CTWP +----------------------+-+ > On 2016/07/29 15:00:44, haraken wrote: > > > > I asked this question before but let me confirm again: What happens if we use > > CTP for the WorkerThreadableLoader => MainThreadLoaderHolder? It will create a > > cycle temporarily but the cycle is explicitly broken when the worker thread > > dies. So it won't cause memory leaks, right? > > > > > > It's a bit more complicated. > > 1. As WorkerThreadableLoader requires users to cancel it appropriately (see > ThreadableLoader's comments), WorkerThreadableLoader <=> > MainThreadableLoaderHelper persistent loop should be no harm (though I don't > feel good with the loop). > > 2. It is not planned now, but I think it's good to move ThreadableLoaderClient > to the heap. With on-heap ThreadableLoaderClient, WorkerThreadableLoader => > ThreadableLoaderClient "raw ptr" will be replaced with a Member ptr. Also, it's > very common that a ThreadableLoaderClient has a ThreadableLoader as Member. > That means there will be a persistent loop from ThreadableLoaderClient to > ThreadableLoaderClient itself. That's problematic. Assume that a > ThreadableLoader has a pre-finalizer that cancels its ThreadableLoader. That > pre-finalizer will not be called because there is a persistent loop. > > 3. As you say that loop will be broken when the thread is terminated but I think > that's not enough. We still see unbound memory consumption increase in a > long-running worker thread. Thanks, makes sense. LGTM.
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 yhirano@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: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
The CQ bit was checked by yhirano@chromium.org
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 yhirano@chromium.org
The CQ bit was checked by yhirano@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 ========== to ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 ==========
Message was sent while issue was closed.
Committed patchset #5 (id:80001)
Message was sent while issue was closed.
Description was changed from ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 ========== to ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961}
Message was sent while issue was closed.
A revert of this CL (patchset #5 id:80001) has been created in https://codereview.chromium.org/2225733002/ by yhirano@chromium.org. The reason for reverting is: To investigate crashes reported at https://crbug.com/634546..
Message was sent while issue was closed.
Description was changed from ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961} ========== to ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961} ==========
reopen
The CQ bit was checked by yhirano@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 checked by yhirano@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 checked by yhirano@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...
cc: hiroshige@ I talked with Hiroshige and decided to revert DocumentThreadableLoader changes.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by yhirano@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org Link to the patchset: https://codereview.chromium.org/2193683004/#ps140001 (title: "revert DocumentThreadableLoader changes")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
relanding...
Message was sent while issue was closed.
Description was changed from ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961} ========== to ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961} ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001)
Message was sent while issue was closed.
Description was changed from ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Cr-Commit-Position: refs/heads/master@{#409961} ========== to ========== Move ThreadableLoader to Oilpan heap (3/3) This CL is a refactoring and does not change the behavior. BUG=587663 Committed: https://crrev.com/2ec047e0061d6c07339e404f918f34459ab6a7b8 Committed: https://crrev.com/3a06b506b18754545e5b50bf66d839c8b152f695 Cr-Original-Commit-Position: refs/heads/master@{#409961} Cr-Commit-Position: refs/heads/master@{#411919} ==========
Message was sent while issue was closed.
Patchset 8 (id:??) landed as https://crrev.com/3a06b506b18754545e5b50bf66d839c8b152f695 Cr-Commit-Position: refs/heads/master@{#411919} |