Skip to content

V
V8
Switch branch/tag
  1. 26 Feb, 2018 1 commit
  3. 22 Feb, 2018 1 commit
    • jgruber's avatar
      Let RelocInfo::Print print the name of code targets · 58fe4d3a
      jgruber authored 
      For builtin and stub code targets, we can be a bit more descriptive and
print their name along with the code kind.

Before:
0x1fafde09c5cf  code target (BUILTIN)  (0x1fafde088280)
0x1fafde09c5f0  code target (STUB)  (0x1fafde084060)

After:
0x1fafde09c5cf  code target (BUILTIN Abort)  (0x1fafde088280)
0x1fafde09c5f0  code target (STUB CEntryStub)  (0x1fafde084060)


Bug: v8:6666
Change-Id: I27d205361748c6bae5e69e14f65efb7f85f23da7
Reviewed-on: https://chromium-review.googlesource.com/928766Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51459}
      58fe4d3a
  5. 21 Feb, 2018 1 commit
  7. 19 Feb, 2018 1 commit
  9. 14 Feb, 2018 1 commit
  11. 13 Feb, 2018 1 commit
  13. 09 Feb, 2018 1 commit
  15. 22 Jan, 2018 2 commits
  17. 18 Jan, 2018 1 commit
  19. 16 Jan, 2018 1 commit
  21. 12 Jan, 2018 1 commit
  23. 05 Dec, 2017 1 commit
  25. 04 Dec, 2017 1 commit
    • Caitlin Potter's avatar
      [builtins] implement RunMicrotasks pump as a code stub · 52ff3ae4
      Caitlin Potter authored 
      - Implement RunMicrotasks in CSA to prevent a potentially large number
  of jumps between C++ and JS code while consuming te queue. Appears to
  provide a ~60% speedup in microtask-heavy code, which from limited
  testing appears to scale linearly.

  The code-stub microtask pump bails out to the old C++ microtask pump
  if it encounters a CallHandlerInfo microtask, and remains in C++ for
  the remainder of the queue (returning to the JS/stub implementation
  after the bailed out queue is exhausted).

- Add a variation of JSEntryStub which enters the new RunMicrotasks code
  stub.

- Add a new RunMicrotasks helper to Execution, which uses the
  RunMicrotasks entry stub.

Bug: 
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
      52ff3ae4
  27. 01 Dec, 2017 1 commit
  29. 27 Nov, 2017 3 commits
  31. 21 Nov, 2017 1 commit
  33. 20 Nov, 2017 3 commits
    • Mircea Trofin's avatar
      Reland "[wasm] Data structures for JIT-ing wasm to native memory." · 0cd6166c
      Mircea Trofin authored 
      This is a reland of c71fd20c
Original change's description:
> [wasm] Data structures for JIT-ing wasm to native memory.
>
> This CL introduces the structures for JIT-ing wasm on the native heap.
> They are described in detail at go/wasm-on-native-heap-stage-1
>
> Briefly:
> - WasmCodeManager manages memory for modules and offers an interior
> pointer lookup (i.e. PC -> WasmCode)
> - WasmCode represents code, including reloc info. It holds wasm
> specific data, like function index, and runtime information, like trap
> handler info.
> - NativeModule manages memory for one module.
>
> Tests cover the allocation and lookup aspects, following that current
> regression tests cover the JITed code. A separate CL will enable
> JITing using the new data structures.
>
> Bug: v8:6876
> Change-Id: I1731238409001fe97c97eafb7a12fd3922da6a42
> Reviewed-on: https://chromium-review.googlesource.com/767581
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49501}

Bug: v8:6876
Change-Id: Ifd1a4c23de8150dbdc75f059cd657e9670b15c9b
Reviewed-on: https://chromium-review.googlesource.com/779680
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49512}
      0cd6166c
    • Mircea Trofin's avatar
      Revert "[wasm] Data structures for JIT-ing wasm to native memory." · 9e45be09
      Mircea Trofin authored 
      This reverts commit c71fd20c.

Reason for revert: msvc is unhappy (https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/208)

Original change's description:
> [wasm] Data structures for JIT-ing wasm to native memory.
> 
> This CL introduces the structures for JIT-ing wasm on the native heap.
> They are described in detail at go/wasm-on-native-heap-stage-1
> 
> Briefly:
> - WasmCodeManager manages memory for modules and offers an interior
> pointer lookup (i.e. PC -> WasmCode)
> - WasmCode represents code, including reloc info. It holds wasm
> specific data, like function index, and runtime information, like trap
> handler info.
> - NativeModule manages memory for one module.
> 
> Tests cover the allocation and lookup aspects, following that current
> regression tests cover the JITed code. A separate CL will enable JITing
> using the new data structures.
> 
> Bug: v8:6876
> Change-Id: I1731238409001fe97c97eafb7a12fd3922da6a42
> Reviewed-on: https://chromium-review.googlesource.com/767581
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49501}

TBR=bradnelson@chromium.org,ulan@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org

Change-Id: Id54deb74782c6f0fd06c61ddcabb727eb7010333
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6876
Reviewed-on: https://chromium-review.googlesource.com/779679Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49503}
      9e45be09
    • Mircea Trofin's avatar
      [wasm] Data structures for JIT-ing wasm to native memory. · c71fd20c
      Mircea Trofin authored 
      This CL introduces the structures for JIT-ing wasm on the native heap.
They are described in detail at go/wasm-on-native-heap-stage-1

Briefly:
- WasmCodeManager manages memory for modules and offers an interior
pointer lookup (i.e. PC -> WasmCode)
- WasmCode represents code, including reloc info. It holds wasm
specific data, like function index, and runtime information, like trap
handler info.
- NativeModule manages memory for one module.

Tests cover the allocation and lookup aspects, following that current
regression tests cover the JITed code. A separate CL will enable JITing
using the new data structures.

Bug: v8:6876
Change-Id: I1731238409001fe97c97eafb7a12fd3922da6a42
Reviewed-on: https://chromium-review.googlesource.com/767581
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49501}
      c71fd20c
  35. 17 Nov, 2017 1 commit
  37. 10 Nov, 2017 1 commit
  39. 30 Oct, 2017 1 commit
    • peterwmwong's avatar
      [builtins] Port WeakMap.p.set and WeakSet.p.add to CSA from JS · 7ae0a2f9
      peterwmwong authored 
      - Add WeakMapPrototypeSet and WeakSetPrototypeAdd TFJ builtins
  - Fast paths for...
    1) existing key
    2) new key when ObjectHashTable has a "sufficient capacity"
- Create WeakCollectionsBuiltinsAssembler to consolidate common WeakMap/WeakSet code generation
- Convert existing WeakMapLookupHashIndex to use WeakCollectionsBuiltinsAssembler

Some quick benchmarks shows performance gains of...
- 1.56x - 1.98x for WeakMap constructor
- 1.66x - 2.06x for WeakSet constructor
- 1.50x - 2.11x for WeakMap.p.set
- 1.54x - 2.26x for WeakSet.p.add

https: //github.com/peterwmwong/v8-perf/blob/master/weakcollection-set/README.md
Bug: v8:5049, v8:6604
Change-Id: I3499d46be6b2b3b1d8d46720ebe86cc5142ee542
Reviewed-on: https://chromium-review.googlesource.com/737935
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49036}
      7ae0a2f9
  41. 25 Oct, 2017 1 commit
  43. 20 Oct, 2017 1 commit
    • Pierre Langlois's avatar
      [arm64] Mark std::printf as an external reference · 3dfb90b6
      Pierre Langlois authored 
      Arm64's implementation of `TurboAssembler::Abort()` supports printing the
bailout reason to the standard output without calling to the runtime. For this
to work, we need access to the host's printf function so we can call it
directly. In the general case, `Abort` does call the runtime, however, we cannot
do it if we want to abort from inside CEntryStub.

Bug: v8:6939
Change-Id: I2a57603cdc182a45cf770f405bd6ae449f40a047
Reviewed-on: https://chromium-review.googlesource.com/730746Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48790}
      3dfb90b6
  45. 19 Oct, 2017 1 commit
  47. 18 Oct, 2017 1 commit
  49. 16 Oct, 2017 1 commit
  51. 13 Oct, 2017 1 commit
  53. 09 Oct, 2017 1 commit
  55. 04 Oct, 2017 1 commit
  57. 28 Sep, 2017 1 commit
    • Enrico Bacis's avatar
      [wasm] Introduce the WasmContext · 6cd7a5a7
      Enrico Bacis authored 
      The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.

This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.

The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution.  The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.

This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).

R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org

Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
      6cd7a5a7
  59. 05 Sep, 2017 1 commit
    • jgruber's avatar
      [builtins] Implement lazy deserialization for TFJ builtins · 79aee245
      jgruber authored 
      This adds support for lazy deserialization of JS-linkage (TFJ) builtins,
still gated behind the --lazy-deserialization flag. If enabled, we
proceed as follows:

During isolate initialization, only eager builtins are deserialized. All
references to lazy builtins are replaced by the DeserializeLazy builtin.
In particular, this happens in the builtin table (Builtins::builtins_)
and in SharedFunctionInfo objects.

When calling into a not-yet deserialized function (i.e. the JSFunction's
code object is the DeserializeLazy builtin), the DeserializeLazy builtin
takes over.  It checks the builtin table to see if the target builtin
(determined by looking at the builtin id stored on the
SharedFunctionInfo) has already been deserialized. If so, it simply
copies the builtin code object to the JSFunction and SharedFunctionInfo.
Otherwise, we enter Runtime::kDeserializeLazy to deserialize the
builtin.

With --lazy-deserialization, isolate deserialization is 11% faster
(1.5ms vs.  1.7ms), and code_space->Size() is 33% lower (984K vs.
1475K).

Moving relocation infos & handler tables out of the partial snapshot
cache would additionally let us save up to 30K per isolate. Adding code
stubs to that list increases further potential savings to 262K.

Bug: v8:6624
Change-Id: I0ac7d05d165d2466998269bd431ac076a311cbeb
Reviewed-on: https://chromium-review.googlesource.com/649166
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47818}
      79aee245
  61. 25 Aug, 2017 2 commits
  63. 23 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored 
      > This reverts commit 42d3d36b.
> 
> Original change's description:
> > [Compiler] Remove code aging support.
> > 
> > Code aging is no longer supported by any remaining compilers now
> > that full codegen has been removed. This CL removes all vestiges of
> > code aging.
> > 
> > BUG=v8:6409
> > 
> > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
> > Reviewed-on: https://chromium-review.googlesource.com/619153
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Marja Hölttä <marja@chromium.org>
> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#47501}
> 
> TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
> 
> Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6409
> Reviewed-on: https://chromium-review.googlesource.com/625998
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47506}

TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com

Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
    • pan.deng@intel.com's avatar
      [X64] replace far jump by near jump · 093dcd9d
      pan.deng@intel.com authored 
      Code size in snapshot can be reduced ~41KB

Contributed by kanghua.yu@intel.com

Bug: None
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ib73af39fe97cd38728affea40c593236f15bf6e5
Reviewed-on: https://chromium-review.googlesource.com/588751
Commit-Queue: Pan Deng <pan.deng@intel.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47531}
      093dcd9d
  65. 22 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "[Compiler] Remove code aging support." · 42d3d36b
      Ross McIlroy authored 
      This reverts commit a205117c.

Reason for revert: breaks Arm64

Original change's description:
> [Compiler] Remove code aging support.
> 
> Code aging is no longer supported by any remaining compilers now
> that full codegen has been removed. This CL removes all vestiges of
> code aging.
> 
> BUG=v8:6409
> 
> Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
> Reviewed-on: https://chromium-review.googlesource.com/619153
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47501}

TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com

Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/625998Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47506}
      42d3d36b