Skip to content

V
V8
Switch branch/tag
  1. 18 Mar, 2019 2 commits
  3. 15 Mar, 2019 1 commit
  5. 12 Mar, 2019 1 commit
  7. 08 Mar, 2019 1 commit
  9. 06 Mar, 2019 1 commit
  11. 26 Feb, 2019 1 commit
  13. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [objects] Free one bit in the SharedFunctionInfo::flags. · 591408cb
      Benedikt Meurer authored 
      We'll need one bit in the SharedFunctionInfo::flags to record whether
it's safe to skip arguments adaptor frames (for v8:8895), so this
just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
redundant, since the same information is already available in the
SharedFunctionInfo::FunctionKindBits, and most places in the code
use that already, with the exception of the JSConstructStubGeneric
builtin.

This changes the JSConstructStubGeneric builtin to just check the
function kind instead of testing the explicit bit, which also makes
this more consistent. It seems like there's not much overhead to
that, doing an additional bitmasking plus two comparisons instead
of one. This shouldn't really matter since invocation and execution
of the constructors is going to dominate and optimized code inlines
all of this anyways. If this turns out to affect performance, we
can still look into encoding the FunctionKindBits more cleverly.

Drive-by-fix: Move the FunctionKindBits first in the flags to avoid
the shift when accessing the function kind. This seems logic, since
for the actual boolean bit fields it doesn't matter where they are
in the flags, whereas for the function kind this saves one shift.

Bug: v8:8834, v8:8895
Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306
Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59821}
      591408cb
  15. 21 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete representations. · adb7e37b
      Benedikt Meurer authored 
      In the Crankshaft days we (mis)used the Representation to also express
the various internal representations that the compiler understands. But
with TurboFan we now have proper MachineRepresentation and MachineType,
which do that independently. So there's no need to have this in the
Representation class anymore, and instead the Representation class only
needs to deal with the field representations.

Bug: v8:8749, v8:8834, v8:8865
Change-Id: I34ea9558b5fdf20d6c7939b52762eaffd4316b06
Reviewed-on: https://chromium-review.googlesource.com/c/1479954
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59750}
      adb7e37b
  17. 15 Feb, 2019 3 commits
  19. 14 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a CallFunctionTemplate builtin. · a2d9924c
      Benedikt Meurer authored 
      When calling into API callbacks from TurboFan optimized, we can
currently only take a fast-path when TurboFan is able to find some
information about the receiver in the graph, or when the API callback
specifies that it neither requires an access check (aka "accepts any
receiver") nor an interface check (aka "compatible receiver check").

This change introduces a new CallFunctionTemplate builtin that sits
in front of the CallApiCallback builtin and does both the access as well
as the interface check as necessary (and raises appropriate exceptions).
This way TurboFan can still call into the API callback via the fast-path
even without ahead knowledge about the receiver, which is significantly
faster than the generic call machinery for API callbacks.

On the test case from the Angular team[1], the interesting metrics
improve from

  DOM_mono: 0.273 ms
  DOM_mega: 0.571 ms
  DOM_call: 0.649 ms

to

  DOM_mono: 0.264 ms
  DOM_mega: 0.572 ms
  DOM_call: 0.368 ms

so the DOM_call is only about **1.4 times slower** than the DOM_mono and
about **1.5 times faster** than the DOM_mega case (compared to **2.4
times slower**). Execution time in the DOM_call was reduced by around
**~45%**.

Currently this new code path is limited to TurboFan optimized code, but
the idea is to eventually migrate the API calls from baseline to also
use the new CSA functionality, but there are lot's of subleties to take
into account, so starting with small changes to get coverage for the
basic building blocks.

[1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html

Bug: v8:8820
Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1470129
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59598}
      a2d9924c
  21. 13 Feb, 2019 2 commits
  23. 08 Feb, 2019 1 commit
  25. 07 Feb, 2019 2 commits
    • Sigurd Schneider's avatar
      [cleanup] Move Code class out of objects.cc · 0c20a4c6
      Sigurd Schneider authored 
      Drive-by: Refactor FlushInstructionCache to its own header. This removes
dependencies of objects.cc and code.cc

Bug: v8:8562
Change-Id: If23f3b9d4f2068e08c61c0f4b070ecfe1b9a6cc0
Reviewed-on: https://chromium-review.googlesource.com/c/1456081Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59435}
      0c20a4c6
    • deepak1556's avatar
      DISALLOW_IMPLICIT_CONSTRUCTORS for MacroAssembler · 9e060e47
      deepak1556 authored 
      When BUILDING_V8_SHARED in release builds __declspec(dllexport)
causes generation of implicit constructors in the forwarding class
while its deleted in TurboAssemblerBase, which leads to compilation
errors like:

In file included from gen/v8/v8_base_jumbo_6.cc:41:
In file included from .\../../v8/src/interface-descriptors.cc:7:
In file included from ../../v8\src/macro-assembler.h:40:
../../v8\src/x64/macro-assembler-x64.h(92,9):  error: call to deleted constructor of 'v8::internal::TurboAssemblerBase'
      : TurboAssemblerBase(std::forward<Args>(args)...) {}
        ^                  ~~~~~~~~~~~~~~~~~~~~~~~~
../../v8\src/x64/macro-assembler-x64.h(536,25):  note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here
class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler {
                        ^
../../v8\src/turbo-assembler.h(127,34):  note: 'TurboAssemblerBase' has been explicitly marked deleted here
  DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase);
                                 ^
1 error generated.

The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913

R=mstarzinger@chromium.org,jgruber@chromium.org,clemensh@chromium.org

Bug: NONE
Change-Id: I87a5a678b8bae13b3adc6f1c6ac0b9313ed18d85
Reviewed-on: https://chromium-review.googlesource.com/c/1454676
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59427}
      9e060e47
  27. 06 Feb, 2019 2 commits
  29. 01 Feb, 2019 1 commit
  31. 31 Jan, 2019 3 commits
  33. 30 Jan, 2019 2 commits
  35. 28 Jan, 2019 2 commits
  37. 25 Jan, 2019 1 commit
  39. 22 Jan, 2019 1 commit
  41. 17 Jan, 2019 3 commits
  43. 16 Jan, 2019 2 commits
    • Benjamin Kramer's avatar
      [assembler] Don't define the reserved name _xgetbv · 15a258b0
      Benjamin Kramer authored 
      _xgetbv is reserved for the implementation and shouldn't be used by user
code. Newer GCCs and clang trunk define _xgetbv, leading to a name
collision if xsaveintrin.h gets included transitively.

This unbreaks building v8 with clang trunk and libstdc++ 4.9, which
happens to pull in xsaveintrin.h transitively through <algorithm>. Newer
versions of libstdc++ don't seem to do that anymore which is why this
issue never showed up before.

R=bmeurer@chromium.org

Change-Id: If94efaf4798e5420738064bcbf26880f904c76a9
Reviewed-on: https://chromium-review.googlesource.com/c/1414858Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58849}
      15a258b0
    • Clemens Hammacher's avatar
      [assembler] Allow to pass custom buffer implementations · 1a3aab51
      Clemens Hammacher authored 
      When generating an Assembler, you currently have two choices: Either
let the Assembler allocate a growable internal buffer, which is owned
by the Assembler. Or provide an externally allocated buffer, which
cannot grow.
This CL changes this interface to allow providing any implementation of
a buffer. The provided buffer can be a view to an externally owned
buffer, which still can grow.
This will be used to split WebAssembly compilation and code submission.
The buffer needs to be able to grow, but cannot be owned by the
Assembler because it has to survive until the code is submitted.

R=mstarzinger@chromium.org

Bug: v8:8689
Change-Id: Ib6c5ebffc8b71d0778944abac34f02c5cc7dbd79
Reviewed-on: https://chromium-review.googlesource.com/c/1411347
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58848}
      1a3aab51
  45. 11 Jan, 2019 1 commit
  47. 10 Jan, 2019 2 commits
    • Jakob Gruber's avatar
      [nojit] Don't allocate executable memory in jitless mode · 566a885d
      Jakob Gruber authored 
      This CL disables RX (read and execute) permissions for Code memory
when in jitless mode. All memory that was previously allocated RX
is now read-only.

Bug: v8:7777
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I52d6ed785d244ec33168a02293c5506d26f36fe8
Reviewed-on: https://chromium-review.googlesource.com/c/1390122
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58692}
      566a885d
    • tzik's avatar
      Shuffle the parameter ordering of JSEntry · 7efa02a3
      tzik authored 
      This moves |root_register_value| parameter of JSEntryFunction to the
first. I.e. the type of entry function will be changed from
 Object*(Object* new_target, Object* target, Object* receiver,
         int argc, Object*** args,
         Address root_register_value)
to
 Object*(Address root_register_value,
         Object* new_target, Object* target, Object* receiver,
         int argc, Object*** args),
and moves all parameter handling except for |root_register_value| from
JSEntryVariant to JSEntryTrampolineHelper.

This is a preparation to add another JS entry point for RunMicrotasks,
whose type will be
 Object*(Address root_register_value, MicrotaskQueue*).
The new entry point requires |root_register_value| to be the first to
share the implementation of the EntryFrame setup with existing ones.

Bug: v8:8124
Change-Id: I675376a2ccd240f61cf04eea6fe9a91031e06ede
Reviewed-on: https://chromium-review.googlesource.com/c/1372857
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58683}
      7efa02a3
  49. 08 Jan, 2019 2 commits
    • Deepti Gandluri's avatar
      [wasm] Add SIMD Shuffles for x64 · f8e2634e
      Deepti Gandluri authored 
      Change-Id: I241565dea56db982a46eed8ecdd2fd2692c368ce
Reviewed-on: https://chromium-review.googlesource.com/c/1395800Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58648}
      f8e2634e
    • Ross McIlroy's avatar
      [Deopt] Remove jump table in prologue of deopt entries. · 4ab96a9a
      Ross McIlroy authored 
      Remove the use of a jump table in the prologue of the deopt entries
and instead pass the bailout id explicitly in a register when calling
the deopt entry routine from optimized code. This unifies the logic
with the way the Arm64 code works. It saves the following amount of
memory in code stubs:

 - arm:  384KB
 - ia32: 480KB
 - x64:  240KB

This could be offset by a slight increase in the size of optimized code
for loading the immediate, however this impact should be minimal and
will scale with the maximum number of bailout ids (e.g., the size of
code will increase by one instruction per bailout id on Arm, therefore
~98,000 bailouts will be needed before the overhead is greater than
the current fixed table size).

Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25
Reviewed-on: https://chromium-review.googlesource.com/c/1398224
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58636}
      4ab96a9a