Skip to content

V
V8
Switch branch/tag
  1. 31 Jul, 2017 1 commit
  3. 28 Jul, 2017 1 commit
  5. 27 Jul, 2017 4 commits
  7. 26 Jul, 2017 1 commit
  9. 21 Jul, 2017 1 commit
  11. 19 Jul, 2017 1 commit
  13. 13 Jul, 2017 1 commit
  15. 04 Jul, 2017 1 commit
  17. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback
vector to store an optimization marker (optimize/in optimization queue)
rather than changing the JSFunction's code object. Then, adapt the
self-healing mechanism to also dispatch based on this optimization
marker. Similarly, replace SFI marking with optimization marker checks
in CompileLazy.

This allows JSFunctions to share optimization information (replacing
shared function marking) without leaking this information across native
contexts. Non I+TF functions (asm.js or --no-turbo) use a
CheckOptimizationMarker shim which generalises the old
CompileOptimized/InOptimizationQueue builtins and also checks the same
optimization marker as CompileLazy and InterpreterEntryTrampoline.

This is a reland of https://chromium-review.googlesource.com/c/509716

Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  19. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored 
      This reverts commit e39c9e02.

Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561

Original change's description:
> [compiler] Drive optimizations with feedback vector
> 
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
> 
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
> 
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true

Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.

This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.

Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  21. 06 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored 
      Properly propagate the fact that the function has a statically known name from
parser to SharedFunctionInfo objects. The empty string that has been set as
name before this CL does not help to distinguish cases like:
  var o1 = { ''(){} };
  var o1 = { [foo()](){} };
or
  var o2 = { get ''(){} };
  var o2 = { get [foo()](){} };

This is a preliminary step for using different layouts for closure objects with
and without computed names.

TBR=bmeurer@chromium.org, marja@chromium.org

Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
Reviewed-on: https://chromium-review.googlesource.com/522073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
  23. 30 May, 2017 1 commit
  25. 26 May, 2017 1 commit
  27. 22 May, 2017 1 commit
  29. 04 May, 2017 1 commit
  31. 03 May, 2017 1 commit
  33. 02 May, 2017 3 commits
  35. 25 Apr, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "[parser] Inital parallel parse tasks implementation." · ef99f666
      Michael Achenbach authored 
      This reverts commit 56a6fda3.

Reason for revert: Makes tsan flaky:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/15038

Original change's description:
> [parser] Inital parallel parse tasks implementation.
> 
> While parsing top-level code eager functions are skipped just like lazy
> ones, but also a parse task is created for each.
> 
> The parse tasks are run by the compiler dispatcher and can be executed
> either on background thread or in idle time.
> After parsing of top-level code finishes it waits for all unfinished
> parser tasks - possibly picking up and executing them on current thread.
> Afterwards parse task results are stitched together with top-level AST,
> in case of failures eager functions are treated just like lazy -
> parsing/compilation is retriggered for them in the runtime and proper
> errors are generated (performance is not optimized for error case at
> all).
> 
> BUG=v8:6093
> 
> Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
> Reviewed-on: https://chromium-review.googlesource.com/483439
> Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44849}

TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6093

Change-Id: I17e689efee7d216d28a94a5c8147022ae7e830dd
Reviewed-on: https://chromium-review.googlesource.com/486883Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44859}
      ef99f666
    • Wiktor Garbacz's avatar
      [parser] Inital parallel parse tasks implementation. · 56a6fda3
      Wiktor Garbacz authored 
      While parsing top-level code eager functions are skipped just like lazy
ones, but also a parse task is created for each.

The parse tasks are run by the compiler dispatcher and can be executed
either on background thread or in idle time.
After parsing of top-level code finishes it waits for all unfinished
parser tasks - possibly picking up and executing them on current thread.
Afterwards parse task results are stitched together with top-level AST,
in case of failures eager functions are treated just like lazy -
parsing/compilation is retriggered for them in the runtime and proper
errors are generated (performance is not optimized for error case at
all).

BUG=v8:6093

Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
Reviewed-on: https://chromium-review.googlesource.com/483439
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarJochen Eisinger <jochen@chromium.org>
Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44849}
      56a6fda3
  37. 19 Apr, 2017 1 commit
    • Adam Klein's avatar
      Remove "calls eval" bit from ParseInfo and PreParseData · 9b512732
      Adam Klein authored 
      There's no reason to keep track, for a preparsed function itself,
whether that function calls eval. All that matters is that the ancestor
scopes are marked as having an inner scope which calls eval. The function
will have its "calls eval" bit persisted if/when it's fully parsed.

The only "behavioral" change in this patch is the removal of a DCHECK.

Bug: v8:6092
Change-Id: I17e396c8a265030fe0ad941707e4a97972e6650b
Reviewed-on: https://chromium-review.googlesource.com/481223
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44732}
      9b512732
  39. 18 Apr, 2017 1 commit
  41. 12 Apr, 2017 1 commit
  43. 11 Apr, 2017 2 commits
  45. 10 Apr, 2017 1 commit
  47. 05 Apr, 2017 3 commits
  49. 28 Mar, 2017 2 commits
  51. 27 Mar, 2017 1 commit
  53. 22 Mar, 2017 1 commit
  55. 16 Mar, 2017 1 commit
  57. 14 Mar, 2017 1 commit