|
|
Created:
5 years, 1 month ago by sof Modified:
5 years, 1 month ago CC:
chromium-reviews, oilpan-reviews, blink-reviews, kouhei+heap_chromium.org, Mads Ager (chromium) Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionPrecisely determine Windows thread stack size (reland)
The Thread Information Block (TIB)'s StackLimit records the end of
the committed area of the thread's stack reservation, hence it cannot be
used to determine the overall size of the reserved stack. Switch to
a VirtualQuery() lookup instead, but taking care to cache the result per
thread so as to avoid calling overhead.
R=haraken
BUG=546396
Committed: https://crrev.com/1f1a89aa631e46b43b81d2b8a212a73e1b9d337e
Cr-Commit-Position: refs/heads/master@{#356521}
Patch Set 1 #Patch Set 2 : add reqd ASSERT_UNUSED() #Patch Set 3 : gracefully handle yellow zone at the end of the stack #
Messages
Total messages: 35 (13 generated)
sigbjornf@opera.com changed reviewers: + oilpan-reviews@chromium.org
please take a look.
LGTM
Description was changed from ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R= BUG=546396 ========== to ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 ==========
The CQ bit was checked by sigbjornf@opera.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1409243011/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1409243011/1
Message was sent while issue was closed.
Committed patchset #1 (id:1)
Message was sent while issue was closed.
Patchset 1 (id:??) landed as https://crrev.com/526a3c557ee6b105ec04441221ee92ea6a447a72 Cr-Commit-Position: refs/heads/master@{#356268}
Message was sent while issue was closed.
A revert of this CL (patchset #1 id:1) has been created in https://codereview.chromium.org/1411013005/ by ellyjones@chromium.org. The reason for reverting is: Broke WebKit build bot: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20x64%20Bui....
Message was sent while issue was closed.
Description was changed from ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 Committed: https://crrev.com/526a3c557ee6b105ec04441221ee92ea6a447a72 Cr-Commit-Position: refs/heads/master@{#356268} ========== to ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 Committed: https://crrev.com/526a3c557ee6b105ec04441221ee92ea6a447a72 Cr-Commit-Position: refs/heads/master@{#356268} ==========
The CQ bit was checked by sigbjornf@opera.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1409243011/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1409243011/20001
Description was changed from ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 Committed: https://crrev.com/526a3c557ee6b105ec04441221ee92ea6a447a72 Cr-Commit-Position: refs/heads/master@{#356268} ========== to ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 ==========
relanding with ASSERT_UNUSED() added.
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 sigbjornf@opera.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1409243011/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1409243011/20001
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/7a23dd77ae2fd895fac2b4dcd8a542f575b6d1ac Cr-Commit-Position: refs/heads/master@{#356287}
Message was sent while issue was closed.
A revert of this CL (patchset #2 id:20001) has been created in https://codereview.chromium.org/1430493002/ by caseq@chromium.org. The reason for reverting is: This apparently caused HeapTest.TraceDeepEagerly to crash on all Win bots (here's an example build: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20x64%20Bui...).
Message was sent while issue was closed.
Description was changed from ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 Committed: https://crrev.com/7a23dd77ae2fd895fac2b4dcd8a542f575b6d1ac Cr-Commit-Position: refs/heads/master@{#356287} ========== to ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 Committed: https://crrev.com/7a23dd77ae2fd895fac2b4dcd8a542f575b6d1ac Cr-Commit-Position: refs/heads/master@{#356287} ==========
Great unit test (TraceDeepEagerly)! :) The scheme used for Windows thread stacks near the end of reserved range to signal near stack exhaustion was new to me -- updated the stack size calculation to align with that. PTAL.
LGTM
Description was changed from ========== Precisely determine Windows thread stack size. The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 Committed: https://crrev.com/7a23dd77ae2fd895fac2b4dcd8a542f575b6d1ac Cr-Commit-Position: refs/heads/master@{#356287} ========== to ========== Precisely determine Windows thread stack size (reland) The Thread Information Block (TIB)'s StackLimit records the end of the committed area of the thread's stack reservation, hence it cannot be used to determine the overall size of the reserved stack. Switch to a VirtualQuery() lookup instead, but taking care to cache the result per thread so as to avoid calling overhead. R=haraken BUG=546396 ==========
On 2015/10/27 19:59:35, haraken wrote: > LGTM Thanks, sorry about the repeat bounces on this one today -- I should have tested more carefully with Windows release bots first. Anyway, heap unittests now pass on win_blink_rel, so will give this one another go..
The CQ bit was checked by sigbjornf@opera.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1409243011/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1409243011/40001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
The CQ bit was checked by sigbjornf@opera.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1409243011/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1409243011/40001
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/1f1a89aa631e46b43b81d2b8a212a73e1b9d337e Cr-Commit-Position: refs/heads/master@{#356521} |