1. 19 Oct, 2017 1 commit
  2. 13 Oct, 2017 1 commit
  3. 11 Oct, 2017 3 commits
    • Eric Holk (eholk)'s avatar
      Reland "Reland "[wasm] trap handlers: fall back on old signal handler"" · 1117da83
      Eric Holk (eholk) authored
      This is a reland of cc237d87
      Original change's description:
      > Reland "[wasm] trap handlers: fall back on old signal handler"
      > 
      > This is a reland of ee4fe896
      > Original change's description:
      > > [wasm] trap handlers: fall back on old signal handler
      > > 
      > > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > > early in the process startup to show stack traces from crashes. We need to make
      > > sure that if V8 does not handle a signal then the existing handler gets a
      > > chance.
      > > 
      > > This change only applies when using V8's default signal handler. When
      > > integrating with the embedder's signal handler the behavior is unchanged.
      > > 
      > > Bug: chromium:771948
      > > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > > Reviewed-on: https://chromium-review.googlesource.com/705823
      > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > > Commit-Queue: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48429}
      > 
      > Bug: chromium:771948
      > Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
      > Reviewed-on: https://chromium-review.googlesource.com/710114
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48435}
      
      Bug: chromium:771948
      Change-Id: I781dfe356a728760090b6ccfa58212096e8f20c8
      Reviewed-on: https://chromium-review.googlesource.com/713956Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48474}
      1117da83
    • Michael Achenbach's avatar
      Revert "Reland "[wasm] trap handlers: fall back on old signal handler"" · 33d4e209
      Michael Achenbach authored
      This reverts commit cc237d87.
      
      Reason for revert: breaks win clang:
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/8538
      
      Original change's description:
      > Reland "[wasm] trap handlers: fall back on old signal handler"
      > 
      > This is a reland of ee4fe896
      > Original change's description:
      > > [wasm] trap handlers: fall back on old signal handler
      > > 
      > > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > > early in the process startup to show stack traces from crashes. We need to make
      > > sure that if V8 does not handle a signal then the existing handler gets a
      > > chance.
      > > 
      > > This change only applies when using V8's default signal handler. When
      > > integrating with the embedder's signal handler the behavior is unchanged.
      > > 
      > > Bug: chromium:771948
      > > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > > Reviewed-on: https://chromium-review.googlesource.com/705823
      > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > > Commit-Queue: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48429}
      > 
      > Bug: chromium:771948
      > Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
      > Reviewed-on: https://chromium-review.googlesource.com/710114
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48435}
      
      TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org
      
      Change-Id: If71f61ae186fc6be2006edeb2dffd7e2b6827d91
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:771948
      Reviewed-on: https://chromium-review.googlesource.com/711854Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48436}
      33d4e209
    • Eric Holk's avatar
      Reland "[wasm] trap handlers: fall back on old signal handler" · cc237d87
      Eric Holk authored
      This is a reland of ee4fe896
      Original change's description:
      > [wasm] trap handlers: fall back on old signal handler
      > 
      > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > early in the process startup to show stack traces from crashes. We need to make
      > sure that if V8 does not handle a signal then the existing handler gets a
      > chance.
      > 
      > This change only applies when using V8's default signal handler. When
      > integrating with the embedder's signal handler the behavior is unchanged.
      > 
      > Bug: chromium:771948
      > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > Reviewed-on: https://chromium-review.googlesource.com/705823
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48429}
      
      Bug: chromium:771948
      Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30
      Reviewed-on: https://chromium-review.googlesource.com/710114Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48435}
      cc237d87
  4. 10 Oct, 2017 2 commits
    • Eric Holk's avatar
      Revert "[wasm] trap handlers: fall back on old signal handler" · 0a97c51f
      Eric Holk authored
      This reverts commit ee4fe896.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] trap handlers: fall back on old signal handler
      > 
      > This is primarily needed to test D8 under ASan. ASan installs a signal handler
      > early in the process startup to show stack traces from crashes. We need to make
      > sure that if V8 does not handle a signal then the existing handler gets a
      > chance.
      > 
      > This change only applies when using V8's default signal handler. When
      > integrating with the embedder's signal handler the behavior is unchanged.
      > 
      > Bug: chromium:771948
      > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      > Reviewed-on: https://chromium-review.googlesource.com/705823
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48429}
      
      TBR=mseaborn@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org,mark@chromium.org
      
      Change-Id: Ib43b096831b15c312b3b460e59f268d5ea903f21
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:771948
      Reviewed-on: https://chromium-review.googlesource.com/710034Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48430}
      0a97c51f
    • Eric Holk's avatar
      [wasm] trap handlers: fall back on old signal handler · ee4fe896
      Eric Holk authored
      This is primarily needed to test D8 under ASan. ASan installs a signal handler
      early in the process startup to show stack traces from crashes. We need to make
      sure that if V8 does not handle a signal then the existing handler gets a
      chance.
      
      This change only applies when using V8's default signal handler. When
      integrating with the embedder's signal handler the behavior is unchanged.
      
      Bug: chromium:771948
      Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
      Reviewed-on: https://chromium-review.googlesource.com/705823Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48429}
      ee4fe896
  5. 28 Sep, 2017 2 commits
    • Mostyn Bramley-Moore's avatar
      [jumbo] add unittests jumbo support · d6ead37d
      Mostyn Bramley-Moore authored
      TBR=jkummerow@chromium.org
      
      Bug: chromium:746958
      Change-Id: I7500b6206c4ceb087672de5b61b7e7ad234bb425
      Reviewed-on: https://chromium-review.googlesource.com/690397
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48213}
      d6ead37d
    • Peter Marshall's avatar
      [cleanup] Replace List with std::vector in api. · 329f6946
      Peter Marshall authored
      The members of HandleScopeImplementer are copied with memcpy when
      the isolate is transferred to another thread. List contained some
      primitives which allowed us to manually free the backing store, which
      was needed in order to ensure that threads would not hold on to
      old pointers and use them later. With std::vector, we can't do that.
      
      Here we change the HandleScopeImplementer to instead use a custom
      structure DetachableVector, which contains a std::vector but allows
      manual detaching and freeing of the backing store. This allows us to
      maintain the old behavior.
      
      Bug: v8:6333
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
      Reviewed-on: https://chromium-review.googlesource.com/660125Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48197}
      329f6946
  6. 16 Sep, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" · 3d046986
      Mircea Trofin authored
      This reverts commit ee5c31f3.
      
      Reason for revert: Fixed compiler failure
      
      Original change's description:
      > Revert "[wasm] A simple allocator datastructure for off-the heap"
      > 
      > This reverts commit 110d9ab0.
      > 
      > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
      > 
      > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
      > 
      > Original change's description:
      > > [wasm] A simple allocator datastructure for off-the heap
      > > 
      > > We'll use this allocator in a follow-up CL to:
      > > - allocate speculative sizes of memory for a module that's being
      > > compiled (e.g. 2*size of wasm code).
      > > - each module will own such a sub-pool, and then use it to allocate
      > > contiguous chunks of memory for code.
      > > 
      > > The underlying assumptions for the chosen allocation strategy is that:
      > > - the allocation granularity for pools is 1 page, so that no one page
      > > is owned by more than one wasm module
      > > - typical pool sizes (given module sizes) are multiple pages.
      > > - modules and module instances are typically few and long lived. Typically,
      > > we expect one module and one instance. 
      > > 
      > > This means we shouldn't expect fragmentations that lead to code being
      > > non-allocatable, or prohibitively many ranges.
      > > 
      > > The data structure just manages ranges of addresses. Virtual memory management
      > > will be separate, as part of the responsibility of a "WasmHeap"
      > > that will be introduced in the future. So will concurrency control.
      > > 
      > > Bug: 
      > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
      > > Reviewed-on: https://chromium-review.googlesource.com/669296
      > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > > Reviewed-by: Eric Holk <eholk@chromium.org>
      > > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48053}
      > 
      > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      > 
      > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Reviewed-on: https://chromium-review.googlesource.com/670141
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48054}
      
      TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/670142
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48055}
      3d046986
    • Mircea Trofin's avatar
      Revert "[wasm] A simple allocator datastructure for off-the heap" · ee5c31f3
      Mircea Trofin authored
      This reverts commit 110d9ab0.
      
      Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
      
      Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
      
      Original change's description:
      > [wasm] A simple allocator datastructure for off-the heap
      > 
      > We'll use this allocator in a follow-up CL to:
      > - allocate speculative sizes of memory for a module that's being
      > compiled (e.g. 2*size of wasm code).
      > - each module will own such a sub-pool, and then use it to allocate
      > contiguous chunks of memory for code.
      > 
      > The underlying assumptions for the chosen allocation strategy is that:
      > - the allocation granularity for pools is 1 page, so that no one page
      > is owned by more than one wasm module
      > - typical pool sizes (given module sizes) are multiple pages.
      > - modules and module instances are typically few and long lived. Typically,
      > we expect one module and one instance. 
      > 
      > This means we shouldn't expect fragmentations that lead to code being
      > non-allocatable, or prohibitively many ranges.
      > 
      > The data structure just manages ranges of addresses. Virtual memory management
      > will be separate, as part of the responsibility of a "WasmHeap"
      > that will be introduced in the future. So will concurrency control.
      > 
      > Bug: 
      > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
      > Reviewed-on: https://chromium-review.googlesource.com/669296
      > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > Reviewed-by: Eric Holk <eholk@chromium.org>
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48053}
      
      TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/670141Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48054}
      ee5c31f3
    • Mircea Trofin's avatar
      [wasm] A simple allocator datastructure for off-the heap · 110d9ab0
      Mircea Trofin authored
      We'll use this allocator in a follow-up CL to:
      - allocate speculative sizes of memory for a module that's being
      compiled (e.g. 2*size of wasm code).
      - each module will own such a sub-pool, and then use it to allocate
      contiguous chunks of memory for code.
      
      The underlying assumptions for the chosen allocation strategy is that:
      - the allocation granularity for pools is 1 page, so that no one page
      is owned by more than one wasm module
      - typical pool sizes (given module sizes) are multiple pages.
      - modules and module instances are typically few and long lived. Typically,
      we expect one module and one instance. 
      
      This means we shouldn't expect fragmentations that lead to code being
      non-allocatable, or prohibitively many ranges.
      
      The data structure just manages ranges of addresses. Virtual memory management
      will be separate, as part of the responsibility of a "WasmHeap"
      that will be introduced in the future. So will concurrency control.
      
      Bug: 
      Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
      Reviewed-on: https://chromium-review.googlesource.com/669296
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48053}
      110d9ab0
  7. 12 Sep, 2017 1 commit
  8. 30 Aug, 2017 2 commits
  9. 07 Aug, 2017 1 commit
    • Clemens Hammacher's avatar
      Move helper struct from logging.h to template-utils.h · 84dc3679
      Clemens Hammacher authored
      I want to reuse the PassType helper in another CL, thus move it from
      logging.h to template-utils.h, and rename it to pass_value_or_ref to
      match other helpers there.
      Also, add a boolean template parameter to declare whether array
      dimensions should be removed. The default is to do so, which helps to
      reduce the number of template instantiations by always passing arrays
      as pointers.
      
      Also, fix the usages in logging.h to actually use that helper when
      instantiating other template functions. This will reduce the number of
      instantiations.
      
      And finally, we now have unit tests for the template utils, to document
      what we expect, and test that this works on all architectures.
      
      R=ishell@chromium.org, tebbi@chromium.org
      
      Change-Id: I1ef5d2a489a5cfc7601c5ab13748674e3aa86cd6
      Reviewed-on: https://chromium-review.googlesource.com/594247
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47191}
      84dc3679
  10. 31 Jul, 2017 1 commit
  11. 28 Jul, 2017 4 commits
  12. 27 Jul, 2017 4 commits
  13. 25 Jul, 2017 1 commit
  14. 14 Jul, 2017 1 commit
  15. 27 Jun, 2017 1 commit
  16. 26 Jun, 2017 1 commit
  17. 23 Jun, 2017 2 commits
  18. 22 Jun, 2017 1 commit
  19. 13 Jun, 2017 1 commit
  20. 19 May, 2017 2 commits
  21. 16 May, 2017 1 commit
  22. 11 May, 2017 1 commit
  23. 09 May, 2017 2 commits
  24. 03 May, 2017 1 commit
    • Jochen Eisinger's avatar
      Reland "Make unittest link correctly again" · 668246a1
      Jochen Eisinger authored
      This reverts commit 5db25a09.
      
      Original change's description:
      > Make unittest link correctly again
      >
      > Remains to port these fixes over to gyp.
      >
      > R=machenbach@chromium.org, jkummerow@chromium.org, mstarzinger@chromium.org
      > BUG=v8:6325
      >
      > Change-Id: I3bebbc6d0ec52fcb60e3d51acd27e616f51d3dbb
      > Reviewed-on: https://chromium-review.googlesource.com/490108
      > Commit-Queue: Jochen Eisinger <jochen@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45026}
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      BUG=v8:6325
      
      Change-Id: Ic3c0ffdf1f13045ea5a3929b720908e0b27a11c3
      Reviewed-on: https://chromium-review.googlesource.com/494566Reviewed-by: 's avatarJochen Eisinger <jochen@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jochen Eisinger <jochen@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45056}
      668246a1