Skip to content

V
V8
Switch branch/tag
  1. 18 Jun, 2020 10 commits
    • Manos Koukoutos's avatar
      [wasm-gc] Change ValueType representation to account for new types · 52f65296
      Manos Koukoutos authored 
      Motivation:
Changes to the typed function references and gc proposals solidified
the notion of heap type, clarified nullable vs. non-nullable reference
types, and introduced rtts, which contain an integer depth field in
addition to a heap type. This required us to overhaul our ValueType
representation, which results in extensive changes.

To keep this CL "small", we do not try to implement the binary encoding
as described in the proposals, but rather devise a simpler one of our
own (see below). Also, we do not try to implement additional
functionality for the new types.

Changes:
- Introduce HeapType. Move heap types from ValueType to HeapType.
- Introduce Nullability for reference types.
- Rework ValueType helper methods.
- Introduce rtts in ValueType with an integer depth field. Include depth
  in the ValueType encoding.
- Make the constructor of ValueType private, instead expose static
  functions which explicitly state what they create.
- Change every switch statement on ValueType::Kind. Sometimes, we need
  nested switches.
- Introduce temporary constants in ValueTypeCode for nullable types,
  use them for decoding.
- In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'.
- Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in
  subtyping.
- kWasmFuncRef initializers are now non-nullable. Initializers are
  only required to be subtypes of the declared global type.
- Change tests and fuzzers as needed.

Bug: v8:7748
Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68408}
      52f65296
    • Dan Elphick's avatar
      Reland "[heap] Make ReadOnlySpace use bump pointer allocation" · 32b911f9
      Dan Elphick authored 
      This reverts commit f78d69fa.

With https://chromium-review.googlesource.com/c/v8/v8/+/2243216,
incorrect MemoryChunk::FromHeapObject uses are now fixed.

Original change's description:
> Revert "[heap] Make ReadOnlySpace use bump pointer allocation"
> 
> This reverts commit 81c34968 and also
> 490f3580 which depends on the former.
> 
> Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
> Original change's description:
> > [heap] Make ReadOnlySpace use bump pointer allocation
> >
> > This changes ReadOnlySpace to no longer be a PagedSpace but instead it
> > is now a BaseSpace. BasicSpace is a new base class that Space inherits
> > from and which has no allocation methods and does not dictate how the
> > pages should be held.
> >
> > ReadOnlySpace unlike Space holds its pages as a
> > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
> > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
> > cannot be held in a heap::List. This is desirable since with pointer
> > compression we would like to remap these pages to different memory
> > addresses which would be impossible with a heap::List.
> >
> > Since ReadOnlySpace no longer uses most of the code from the other
> > Spaces it makes sense to simplify its memory allocation to use a simple
> > bump pointer and always allocate a new page whenever an allocation
> > exceeds the remaining space on the final page.
> >
> > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
> > Commit-Queue: Dan Elphick <delphick@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68137}
> 
> TBR=ulan@chromium.org,delphick@chromium.org
> 
> # Not skipping CQ checks because original CL landed > 1 day ago.
> 
> Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68211}

TBR=ulan@chromium.org,delphick@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68407}
      32b911f9
    • zeynepCankara's avatar
      [tools] Map search bar feature added, map id changed from int to string · af5f156d
      zeynepCankara authored 
      Change-Id: Icc37fc091086a3239a1b080ca2829efcda97f328
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245601
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68406}
      af5f156d
    • Ross McIlroy's avatar
      [Arm64] Reduce default stack-size to be the same as on Arm. · 79ed10cf
      Ross McIlroy authored 
      When running in single-process mode for Webview, the stack limit is
initialized from a point closer to the top of stack limit. This causes
can cause crashes since the stack limit might be higher than the actual
native stack limit (which is 1MB on Android). As such, use the same
slightly lower stack limit on Arm64 as we do on Arm to give more slack.

BUG=v8:10575

Change-Id: I0cdd0cb4b38aafcb4e158ed639ecf3bba2edb785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250241
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68405}
      79ed10cf
    • Frank Tang's avatar
      Roll test262 · 080a6c77
      Frank Tang authored 
      https://chromium.googlesource.com/external/github.com/tc39/test262/+log/f89ea875..8d3dd2d

8d3dd2d Sync the test w/ changes in intl-datetime-style 43 by Frank Tang · 15 hours ago master
2dcdba9 Simplify tests by Alexey Shvayka · 15 hours ago
23417d9 Test %TypedArray%.prototype.set with primitives by Alexey Shvayka · 15 hours ago

Bug: v8:7834
Change-Id: I39b62aa1f4800349a009035e704bd4a93223174b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2251174Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68404}
      080a6c77
    • Clemens Backes's avatar
      [wasm] Split decoding into individual functions · d8a32a96
      Clemens Backes authored 
      Instead of having a loop with one big switch for handling the different
opcodes, split the decoding into one handler per opcode and call them
via an opcode handler table.
The compiler will generate similar code for this new approach (the big
switch is also compiled into a table lookup and an indirect jump). The
main difference is that it's now calls instead of jumps. This has a
slight performance impact, but allows to look at the decoding logic of
individual opcodes in isolation and see optimization opportunities much
easier. It also allows spot very easily in profilers on which opcodes
most time is spent.

The different opcode handlers are still implemented via the same switch
as before, but since the opcode is a template argument (hence static)
the compiler will eliminate the switch and generate the small handlers
we want.
I plan to actually remove the switch and break up the big generic
{DecodeOp} method into one method per opcode.

R=thibaudm@chromium.org

Bug: v8:10576
Change-Id: Ic2c1e2fe5e98df52a7079ace305cf77340dcbf35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249664Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68403}
      d8a32a96
    • Jakob Gruber's avatar
      Use the new CONSTEXPR_DCHECK macro · 09fd7c71
      Jakob Gruber authored 
      Introduced in https://crrev.com/c/2250243.

CONSTEXPR_DCHECK(cond) replaces the longer

 #if V8_HAS_CXX14_CONSTEXPR
     DCHECK(cond);
 #endif

pattern.

Change-Id: I636e5b4b40bffb29b2e82c81285b2ef78a822745
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250244Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68402}
      09fd7c71
    • Michael Achenbach's avatar
      [fuzzing] Use --fuzzing flag for allowed runtime functions · 3864e1f2
      Michael Achenbach authored 
      This subsumes the old behavior of --allow-natives-for-fuzzing under
--fuzzing as well. Both flags are used in a redundant way in fuzz
configs. Only --allow-natives-for-fuzzing wasn't specified as a
required argument, leading to the bug below.

We still need the flag --allow-natives-for-differential-fuzzing
to allow different functions when using differential fuzzing.

Bug: chromium:1094866
Change-Id: I398791779e58ed4d80e896c1cfea343848159212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68401}
      3864e1f2
    • Jakob Gruber's avatar
      [regexp] Additional range checks · 365f46d0
      Jakob Gruber authored 
      ... in regexp bytecode {length,name} accessors and in peephole
optimization.

Bug: chromium:1095866
Change-Id: I78c89d35d796776b61eabf82b921f7582e431be7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250243Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68400}
      365f46d0
    • Clemens Backes's avatar
      [liftoff] Speed up check for debug info · f38e4093
      Clemens Backes authored 
      The {NextInstruction} method is quite hot, since it's called for every
since Wasm instruction. It currently does several checks to figure out
if
- a breakpoint needs to be emitted,
- extra source positions are needed, or
- tracing is active.

The first two can only happen if we are generating debug code, hence
check for that first. The last can only happen in debug mode, so it's
not an issue in production.

Finally, outline the emission of debug information. This leads to
inlining of the {NextInstruction} method into callers, where it is a
single check followed by a call to {EmitDebuggingInfo} (in release
mode).

R=thibaudm@chromium.org

Bug: v8:10576
Change-Id: I5047406f55cd14c6c639528ef6e3422af27d16b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249671
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68399}
      f38e4093
  3. 17 Jun, 2020 21 commits
  5. 16 Jun, 2020 9 commits