1. 02 Aug, 2019 12 commits
  2. 01 Aug, 2019 17 commits
  3. 31 Jul, 2019 11 commits
    • Ng Zhi An's avatar
      Remove stale comments · c81dd313
      Ng Zhi An authored
      Bug: v8:8425
      Change-Id: I4c883726daee1ab244e4bc2ce202cacf9bd3d50c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726400
      Auto-Submit: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63016}
      c81dd313
    • Ng Zhi An's avatar
      Fix bit mask for IsCanonical · ba4ec5a6
      Ng Zhi An authored
      The mask should cover the sign (1 bit), exponent (11 bits) and quiet bit (1 bit) of significand, total of 13 bits. The old mask only covered 9 bits.
      
      Change-Id: I6ec402b4cec34978eac8fa3e5452ad22540a93ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726984Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63015}
      ba4ec5a6
    • Z Nguyen-Huu's avatar
      call ProxyDeleteProperty inside DeleteProperty · e88a8ae2
      Z Nguyen-Huu authored
      Instead of having fast path for proxy only in Reflect.deleteProperty, it
      is also in delete operator.
      
      Bug: v8:6664
      Change-Id: I3db919953e31f51a5dc4a504062bd691a6e17446
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717660
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63014}
      e88a8ae2
    • Dan Elphick's avatar
      [compiler] Always collect source positions for wrapped functions · 43c8538d
      Dan Elphick authored
      Wrapped functions don't recompile properly with lazy source positions so
      just force them to always collect the source positions.
      
      Fixes cctest/test-compiler/CompileFunctionInContext in the presence of
      --enable-lazy-source-positions and --stress-lazy-source-positions.
      
      Bug: v8:8510
      Change-Id: I2402a441d4930be11dc037c6041cb577a63a3529
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709427
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Auto-Submit: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63013}
      43c8538d
    • Deepti Gandluri's avatar
      Make atomic operations effectful. · 289aa11b
      Deepti Gandluri authored
      Bug: v8:9536
      Change-Id: Ie9c47493ab29f604d6e43ef318e08618ee527fc3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728329Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63012}
      289aa11b
    • Francis McCabe's avatar
      Revert ""Reland x3 [arraybuffer] Rearchitect backing store ownership"" · 195679de
      Francis McCabe authored
      This reverts commit df8e6177.
      
      Reason for revert: Multiple flakes in apparently related areas:
      
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0
      
      Original change's description:
      > "Reland x3 [arraybuffer] Rearchitect backing store ownership"
      > 
      > This is a reland of bc33f5ae
      > 
      > Original change's description:
      > > [arraybuffer] Rearchitect backing store ownership
      > >
      > > This CL completely rearchitects the ownership of array buffer backing stores,
      > > consolidating ownership into a {BackingStore} C++ object that is tracked
      > > throughout V8 using unique_ptr and shared_ptr where appropriate.
      > >
      > > Overall, lifetime management is simpler and more explicit. The numerous
      > > ways that array buffers were initialized have been streamlined to one
      > > Attach() method on JSArrayBuffer. The array buffer tracker in the
      > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
      > > and the construction and destruction of the BackingStore object itself
      > > handles the underlying page or embedder-allocated memory.
      > >
      > > The embedder API remains unchanged for now. We use the
      > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
      > > keep the backing store alive properly, even in the case of aliases
      > > from live heap objects. Thus the embedder has a lower chance of making
      > > a mistake. Long-term, we should move the embedder to a model where they
      > > manage backing stores using shared_ptr to an opaque backing store object.
      > 
      > R=​mlippautz@chromium.org
      > BUG=v8:9380,v8:9221,chromium:986318
      > TBR=ulan@chromium.org
      > 
      > Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63007}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org
      
      Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9380, v8:9221, chromium:986318
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63011}
      195679de
    • Clemens Hammacher's avatar
      Skip broken test on TSan · a48f88ec
      Clemens Hammacher authored
      R=ulan@chromium.org
      
      Bug: v8:9380
      No-Try: true
      Change-Id: I319bbc607a738d78cb797691bcfcb9484f416324
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728619
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63010}
      a48f88ec
    • Seth Brenith's avatar
      Reland "[regexp] Better quick checks on loop entry nodes" · bea0ffd0
      Seth Brenith authored
      This is a reland of 4b15b984
      
      Updates since original: fix an arithmetic overflow bug, remove an invalid
      DCHECK, add a unit test that would trigger that DCHECK.
      
      Original change's description:
      > [regexp] Better quick checks on loop entry nodes
      >
      > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      > change is inspired by attempting to exit earlier from generated RegExp
      > code, when no further matches are possible because any match would be
      > too long. The motivating example this time is the following expression,
      > which tests whether a string of Unicode playing cards has five of the
      > same suit in a row:
      >
      > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      >
      > A human reading this expression can readily see that any match requires
      > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      > each repeated option reports its minimum distance to the end of a match
      > as zero. This is correct, because the LoopChoiceNode's behavior depends
      > on additional state (the loop counter). However, the preceding node, a
      > SET_REGISTER action that initializes the loop counter, could confidently
      > state that it consumes at least 10 characters. Furthermore, when we try
      > to emit a quick check for that action, we could follow only paths from
      > the LoopChoiceNode that are possible based on the minimum iteration
      > count. This change implements both of those "could"s.
      >
      > I expect this improvement to apply pretty broadly to expressions that
      > use minimum repetition counts and that don't meet the criteria for
      > unrolling. In this particular case, I get about 12% improvement on the
      > overall UniPoker test, due to reducing the execution time of this
      > expression by 85% and the execution time of another similar expression
      > that checks for n-of-a-kind by 20%.
      >
      > Bug: v8:9305
      >
      > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62963}
      
      Bug: v8:9305
      Change-Id: I992070d383009013881bf778242254c27134b650
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63009}
      bea0ffd0
    • Seth Brenith's avatar
      Reland "Add postmortem debugging helper library" · 0921e8f2
      Seth Brenith authored
      This is a reland of 517ab73f
      
      Updates since original: now compressed pointers passed to the function
      GetObjectProperties are required to be sign-extended. Previously, the
      function allowed zero-extended values, but that led to ambiguity on
      pointers like 0x88044919: is it compressed or is the heap range actually
      centered on 0x100000000?
      
      Original change's description:
      > Add postmortem debugging helper library
      >
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      >
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      >
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      >
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      >
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      >
      > Bug: v8:9376
      >
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      Bug: v8:9376
      Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63008}
      0921e8f2
    • Ben L. Titzer's avatar
      "Reland x3 [arraybuffer] Rearchitect backing store ownership" · df8e6177
      Ben L. Titzer authored
      This is a reland of bc33f5ae
      
      Original change's description:
      > [arraybuffer] Rearchitect backing store ownership
      >
      > This CL completely rearchitects the ownership of array buffer backing stores,
      > consolidating ownership into a {BackingStore} C++ object that is tracked
      > throughout V8 using unique_ptr and shared_ptr where appropriate.
      >
      > Overall, lifetime management is simpler and more explicit. The numerous
      > ways that array buffers were initialized have been streamlined to one
      > Attach() method on JSArrayBuffer. The array buffer tracker in the
      > GC implementation now manages std::shared_ptr<BackingStore> pointers,
      > and the construction and destruction of the BackingStore object itself
      > handles the underlying page or embedder-allocated memory.
      >
      > The embedder API remains unchanged for now. We use the
      > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
      > keep the backing store alive properly, even in the case of aliases
      > from live heap objects. Thus the embedder has a lower chance of making
      > a mistake. Long-term, we should move the embedder to a model where they
      > manage backing stores using shared_ptr to an opaque backing store object.
      
      R=mlippautz@chromium.org
      BUG=v8:9380,v8:9221,chromium:986318
      TBR=ulan@chromium.org
      
      Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63007}
      df8e6177
    • Milad Farazmand's avatar
      PPC/s390: [deoptimizer, cleanup] Don't store values of single precision fp registers · 9ed91576
      Milad Farazmand authored
      Port 556e4859
      
      Original Commit Message:
      
          Instead of storing the values of the single precision floating point registers,
          get their values from the aliased double precision registers.
      
          This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total)
          and 128 bytes in the RegisterValues class.
      
      R=joey.gouly@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: If38a721cfaefb7980902f4f963119cb88061e342
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726857Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#63006}
      9ed91576