Skip to content

V
V8
Switch branch/tag
  1. 24 Oct, 2019 1 commit
  3. 21 Oct, 2019 1 commit
  5. 17 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Move Context::native_context to the map" · 3cad6bf5
      Toon Verwaest authored 
      This is a reland of c7c47c68.

This makes TSAN happy in addition to:

Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.

Bug: v8:9860
Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org

Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}

Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64360}
      3cad6bf5
  7. 16 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[runtime] Move Context::native_context to the map"" · 38301e7b
      Sathya Gunasekaran authored 
      This reverts commit c7c47c68.

Reason for revert: breaks TSAN
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738

Original change's description:
> Reland "[runtime] Move Context::native_context to the map"
> 
> This is a reland of f05bae1e
> 
> Previously I presumed that the context read from a frame in the profiler was
> a valid context. Turns out that on non-intel we're not guaranteed that the
> frame is properly set up. In the case we looked at, the profiler took a
> sample right before writing the frame marker indicating a builtin frame,
> causing the "context" pointer from that frame to be a bytecode array. Since
> we'll read random garbage on the stack as a possible context pointer, I made
> the code reading the native context from it a little more defensive.
> 
> Bug: v8:9860
> 
> Original change's description:
> > [runtime] Move Context::native_context to the map
> >
> > Remove the native context slot from contexts by making context maps
> > native-context-specific. Now we require 2 loads to go from a context to the
> > native context, but we have 1 field fewer to store when creating contexts.
> >
> > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64296}
> 
> Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64314}

TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com

Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64316}
      38301e7b
    • Toon Verwaest's avatar
      Reland "[runtime] Move Context::native_context to the map" · c7c47c68
      Toon Verwaest authored 
      This is a reland of f05bae1e

Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.

Bug: v8:9860

Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}

Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64314}
      c7c47c68
  9. 15 Oct, 2019 2 commits
  11. 09 Oct, 2019 1 commit
  13. 26 Sep, 2019 2 commits
  15. 25 Sep, 2019 1 commit
  17. 16 Sep, 2019 1 commit
  19. 13 Sep, 2019 1 commit
  21. 12 Sep, 2019 1 commit
  23. 10 Sep, 2019 2 commits
  25. 09 Sep, 2019 1 commit
    • Tom Tan's avatar
      Avoid defining class name `Label` as type alias in cctest because it is used by V8 · 8d107684
      Tom Tan authored 
      It is not recommended to define type alias in C++ header file. cctest defines
type alias `using Label=CodeAssemblerLabel` in anonymous namespace under
namespace `v8::internal::compiler` in test-code-assembler.cc. This is fine
because this type alias is expected to take effect only in this .cc file. But in
jumbo build, multiple source files are combined as a single one, and the
previous `Label` type alias could shadow definition of `Label` from other header
file (for example, v8/src/codegen/label.h which is included by another .cc file)
This is totally unexpected and triggers bad class layout and accessing in the
latter .cc file for the places where `Label` is referenced.

This change fixes cctest from Windows ARM64 jumbo build, but it applies to
other architectures too.

Bug: chromium:893460
Change-Id: Ib2e9df76f6e3371b3940649668c5d13e6b36f028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1788537Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63605}
      8d107684
  27. 29 Aug, 2019 1 commit
  29. 28 Aug, 2019 1 commit
  31. 26 Aug, 2019 1 commit
  33. 23 Aug, 2019 2 commits
  35. 22 Aug, 2019 1 commit
  37. 01 Aug, 2019 2 commits
  39. 30 Jul, 2019 1 commit
  41. 26 Jul, 2019 1 commit
  43. 17 Jul, 2019 1 commit
  45. 12 Jul, 2019 1 commit
    • Nico Hartmann's avatar
      [turbofan] Push BigInt truncation over addition and heap constants · 99df710d
      Nico Hartmann authored 
      This change implements lowering of speculative BigInt addition as well as
BigInt heap constants to corresponding int64 versions, if they are used in
a context where the result is truncated to the least significant 64 bits
(e.g. using asUintN). The JSHeapBroker is extended to provide access to the
BigInt's least significant digit during concurrent compilation. The BigInt
context (required to introduce correct conversions) is recognized in the
RepresentationChanger by either the output type propagated downward or the
TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind
may only be set by nodes that may potentially deopt (and sit in the effect
chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN.

This CL contains a simple fix to prevent int64-lowered BigInts to flow into
state values as the deoptimizer cannot handle them yet. A more sophisticated
solution to allow the deoptimizer to materialize truncated BigInts will be
added in a following CL.

Bug: v8:9407
Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62665}
      99df710d
  47. 11 Jul, 2019 1 commit
  49. 08 Jul, 2019 1 commit
  51. 05 Jul, 2019 1 commit
  53. 03 Jul, 2019 1 commit
  55. 27 Jun, 2019 1 commit
  57. 26 Jun, 2019 1 commit
    • Mike Stanton's avatar
      [TurboFan] Serializing context information · 386ff6e5
      Mike Stanton authored 
      In TurboFan, context specialization is an optimization that tries to
either replace the load of a value from the context with a constant,
or if that can't be achieved, at least reduce the hops up the
context chain by starting a walk to the required depth from the
first constant context that it can reach.

Currently, this optimization is performed by looking into the
heap during a reducer pass. With fully concurrent TurboFan, we
need to instead gather information about contexts we may want
to perform this optimization on during serialization.

This CL adds functionality to the serializer to recognize and
model operations that affect the context register. We add to the
hinting structure already used by the serializer. There is
a new type of hint: a VirtualContext. This is a tuple consisting
of a handle to a Context, and a distance field that indicates how
far away in a to-be-realized chain this VirtualContext sits from
the context in the handle. For example:

bytecode stream:
...
CreateBlockContext
...

After a block context is created, the accumulator now contains
a VirtualContext Hint with a distance of 1 from any context hints
that we are keeping track of in the current context register.

More details in the design doc here:
https://docs.google.com/document/d/1Y0LKKCEenLWyAZTetoAIpKTZRCxaNdkYV8X1GaCax2A/edit?usp=sharing

Change-Id: I63732ebd106cc138fb1e9789d0676ece63e15d27
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605941
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62370}
      386ff6e5
  59. 18 Jun, 2019 1 commit
  61. 12 Jun, 2019 1 commit
  63. 31 May, 2019 1 commit
  65. 29 May, 2019 1 commit
  67. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored 
      This replaces all typedefs that define types and not functions by the
equivalent "using" declaration.

This was done mostly automatically using this command:
ag -l '\btypedef\b' src test | xargs -L1 \
     perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'

Patchset 2 then adds some manual changes for typedefs for pointer types,
where the regular expression did not match.

R=mstarzinger@chromium.org
TBR=yangguo@chromium.org, jarin@chromium.org

Bug: v8:9183
Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae