1. 02 Aug, 2019 3 commits
    • Ng Zhi An's avatar
      [wasm-simd] Implement F64x2 min max for x64 · e17ac925
      Ng Zhi An authored
      Also add a IsExtreme(double) overload.
      This wasn't causing issues because there was no codepath
      which exercised it (only approx operations did).
      
      Change-Id: If7583fb567137c428d16c0d2cdfc37e086f7f3fd
      Bug: v8:8460
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726675Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63053}
      e17ac925
    • Ulan Degenbaev's avatar
      "Reland x4 [arraybuffer] Rearchitect backing store ownership" · 5611f70b
      Ulan Degenbaev authored
      This is a reland of bc33f5ae
      
      Contributed by titzer@chromium.org
      
      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.
      
      TBR=yangguo@chromium.org
      
      BUG=v8:9380,v8:9221,chromium:986318
      
      Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63041}
      5611f70b
    • Georg Schmid's avatar
      [torque] Infer type arguments of generic struct initializers · b1db8d84
      Georg Schmid authored
      Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct
      
        struct Box<T: type> {
          const value: T;
        }
      
      one would initialize a new box using
      
        const aSmi: Smi = ...;
        const box = Box<Smi> { value: aSmi };
      
      With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables.
      
      Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types).
      
      R=jgruber@chromium.org, tebbi@chromium.org
      
      Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63036}
      b1db8d84
  2. 01 Aug, 2019 5 commits
  3. 31 Jul, 2019 7 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
    • 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
    • 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
    • Tom Tan's avatar
      Unwind V8 frames correctly on Windows ARM64 · 3f1f001a
      Tom Tan authored
      On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend
      doesn't emit unwinding info and also because it doesn't emit ABI compliant
      stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and
      documented below:
      
      https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0
      
      This problem can be fixed similarly for Windows ARM64 by observing that V8
      frames usually all have the same prolog which maintains a chain via frame
      pointer (fp or x29 register).
      
      stp fp, lr, [sp, ...]
      
      One exception is JSEntry which stops fp pointer chain and needs to be handled
      specially.
      
      So it is possible to define XDATA with UNWIND_CODE which specify how Windows
      should walk through V8 dynamic frames. The same as X64, since V8 Code objects
      are all allocated in the same code-range for an Isolate, it is possible to
      register at most 2 XDATA and a group of PDATA entries to cover stack walking
      for all the code generated inside that code-range. This is more than 1
      PDATA/XDATA because according to the Windows ARM64 exeption handling document,
      1 PDATA can cover less than 1MB code range (see below doc).
      
      https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling
      
      This PR implements stackwalk for Windows ARM64 to be on par with X64, including
      embedded builtins, jitted code and wasm jitted code, but not including register
      handler for handling exception only, because there is no backward compatibility
      to maintain for Windows ARM64 which was released since 1709 windows build.
      
      Bug: chromium:893460
      Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63002}
      3f1f001a
  4. 30 Jul, 2019 12 commits
  5. 29 Jul, 2019 6 commits
  6. 27 Jul, 2019 1 commit
  7. 26 Jul, 2019 2 commits
  8. 25 Jul, 2019 4 commits
    • Ng Zhi An's avatar
      [wasm-simd] Implement I64x2 Shl ShrS ShrU for arm64 · 0cedd864
      Ng Zhi An authored
      Bug: v8:8460
      Change-Id: I70bdd71909fd103f3cc537d3184d2f7225cf8cfa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719034
      Auto-Submit: Zhi An Ng <zhin@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62929}
      0cedd864
    • Ng Zhi An's avatar
      [wasm-simd] Implement I64x2 splat extract_lane replace_lane for arm64 · 1a1138f5
      Ng Zhi An authored
      Bug: v8:8460
      Change-Id: Ic92efbcb7c64184c237d0fb00c3c7aa75323a3e9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717662
      Auto-Submit: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62928}
      1a1138f5
    • Zhi An Ng's avatar
      Revert "[wasm] Simplify module creation" · bf7284b9
      Zhi An Ng authored
      This reverts commit 425fa3ae.
      
      Reason for revert: test failure https://bugs.chromium.org/p/v8/issues/detail?id=9554 reverting the root cause has merge conflicts due to changes in same file
      
      Original change's description:
      > [wasm] Simplify module creation
      > 
      > This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
      > The intent is to make the various ways of creating a module (sync,
      > async, deserialize, import) more similar.
      > 
      > After this change, a NativeModule will always be created before a
      > WasmModuleObject. This will make it easier to look up a cached
      > NativeModule given its wire bytes.
      > 
      > The following changes are made:
      > 
      > * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
      >   size estimate by default. A different code size estimate is only used in
      >   tests.
      > * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
      >   assuming the array was created with the correct size. This simplifies
      >   WasmModuleObject::New(), and matches what CompileToNativeModule()
      >   does.
      > * Remove the WasmModuleObject::New() constructor that creates a
      >   NativeModule. This case was only used in DeserializeNativeModule() and
      >   in test code.
      > 
      > Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
      > Commit-Queue: Ben Smith <binji@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62925}
      
      TBR=binji@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I8dcad7ddcd4601f657b6263bf22009907284fce3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719230Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62926}
      bf7284b9
    • Ben Smith's avatar
      [wasm] Simplify module creation · 425fa3ae
      Ben Smith authored
      This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
      The intent is to make the various ways of creating a module (sync,
      async, deserialize, import) more similar.
      
      After this change, a NativeModule will always be created before a
      WasmModuleObject. This will make it easier to look up a cached
      NativeModule given its wire bytes.
      
      The following changes are made:
      
      * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
        size estimate by default. A different code size estimate is only used in
        tests.
      * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
        assuming the array was created with the correct size. This simplifies
        WasmModuleObject::New(), and matches what CompileToNativeModule()
        does.
      * Remove the WasmModuleObject::New() constructor that creates a
        NativeModule. This case was only used in DeserializeNativeModule() and
        in test code.
      
      Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62925}
      425fa3ae