Skip to content

V
V8
Switch branch/tag
  1. 27 Jan, 2020 7 commits
    • Steve Blackburn's avatar
      Refactor deserialization allocation. · 49f60a3b
      Steve Blackburn authored 
      Deserialization bypasses the heap allocators, bumping pointers into the
spaces directly, instead.  So the deserializer is tightly coupled to the
implementation of the existing collector.

Here I've added an interface to heap.h for this purpose.  This CL
leaves things as-is unless the TPH is enabled, in which case the new
interface is used.

Future work: use the heap.h interface in all cases.

Bug: v8:9533

Change-Id: I3b1cc81870b347fbfb509ddb4031bd3781710240
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019482
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65992}
      49f60a3b
    • Peter Marshall's avatar
      [inspector] Add a test for const declaration and side effects · 73f4ac62
      Peter Marshall authored 
      Add a test that does the same thing the devtools-frontend does when
evaluating console inputs.

1) Declare a const variable with throwOnSideEffect=true. This should
throw.
2) Declare the same const variable with throwOnSideEffect=false.
This should successfully declare the variable.

Previously it could be the case that even though we threw in 1), the
variable would fail to be initialized in 2) with a re-declaration
error.

Bug: chromium:1043151
Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65991}
      73f4ac62
    • Liviu Rau's avatar
      [fuchsia] Finalize rename & add test configuration for test runner · d7a2973f
      Liviu Rau authored 
      Bug: chromium:1033865
Change-Id: I63999575d4962124a4d9a64c4e661900aec5fa6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019167Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65990}
      d7a2973f
    • Andreas Haas's avatar
      [x64] Introduce negb and negw instructions · 911f38c4
      Andreas Haas authored 
      This CL introduces the negb and negw instructions (8-bit and 16-bit
versions of neg) in the x64 assembler. These instructions are needed to
implement I32AtomicSub8U and similar WebAssembly instructions
efficiently.

The existing implementation was embedded in a generic macro, and it was
difficult to change it without introducing also the 8-bit and 16-bit
versions of many other instructions. This would have introduced a lot
of dead code. Instead this CL extracted the neg instructions from the
macro and implements them directly. This should be fine because the
assembler does not change much, and approachability of the code is
improved.

R=clemensb@chromium.org

Bug: v8:10108
Change-Id: I46099bbebd47f864311a67da3ba8ddc4fe4cd35d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019165
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65989}
      911f38c4
    • Clemens Backes's avatar
      [wasm] Pass breakpoints to Liftoff compiler · 261a22e2
      Clemens Backes authored 
      This extends the API to pass breakpoint information to Liftoff. The
Liftoff compiler identifies the places where breakpoints should be set,
but does not emit breakpoints yet.
This allows us to see the performance overhead of just checking where to
emit breakpoints (which should be negligible).

R=thibaudm@chromium.org

Bug: v8:10147
Change-Id: I3fd40ab9009e9c317a26f70b4f06db512f96a763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019169Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65988}
      261a22e2
    • Justin Ridgewell's avatar
      Fix two overflow cases in SourceMap VLQ decoding · 615ecdf8
      Justin Ridgewell authored 
      These both have to do with extremely large numbers, so it's unlikely to cause a problem in practice. Still, correctness.

First, encoding `-2147483648` in VLQ returns the value `"B"`. When decoding, we get the value `1` after reading the base64. We then check if the first bit is set (it is) to see if we should negate it, then we shift all bits right once. Now, `value` will be `0` and `negate` will be `true`. So, we'd return `-0`. Which is a bug! `-0` isn't `-2147483648`, and we've broken a round trip.

Second, encoding any number with the 31st bit set, we'd return the opposite sign. Let's use `1073741824`. Encoding, we get `"ggggggC"`. When decoding, we get the value `-2147483648` after reading the base64. Notice, it's already negative (the 32nd bit is set, because the 31st was set and we shifted everything left once). We'd then check the first bit (it's not) and shift right. But we used `>>`, which does not shift the sign bit. We actually wanted `>>>`, which will. Because of that bug, we get back `-1073741824` instead of the positive `1073741824`. It's even worse if the 32nd and 31st bits are set, `-1610612736` becomes `536870912` after a round trip.

I recently fixed the same two bugs in Closure Compiler: https://github.com/google/closure-compiler/commit/584418eb

Change-Id: Ib6592ad50ae3764479c1a766bbb19042ee83b99d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018882
Auto-Submit: Justin Ridgewell <jridgewell@google.com>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65987}
      615ecdf8
    • Jakob Gruber's avatar
      [regexp] Correctly escape a backslash-newline sequence · 7d1f95d6
      Jakob Gruber authored 
      When printing the source string, a backslash-newline sequence ('\\\n',
'\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
'\u2028', '\u2029', respectively. Prior to this CL it was formatted as
a backslash followed by the literal newline character.

Bug: v8:8615
Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65986}
      7d1f95d6
  3. 24 Jan, 2020 23 commits
  5. 23 Jan, 2020 10 commits