Skip to content

V
V8
Switch branch/tag
  1. 04 Sep, 2019 1 commit
  3. 29 Aug, 2019 2 commits
  5. 13 Aug, 2019 1 commit
  7. 25 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [regexp] Use stricter bounds check to avoid additional iteration · f42b1a5d
      Seth Brenith authored 
      The motivating example is JetStream 2's UniPoker test, which tests
whether a sorted string of Unicode playing cards contains a five-card
straight using a regular expression. In the top-level generated loop for
this RegExp, we see this loop exit condition:

00000350000C2067    27  83fffe         cmpl rdi,0xfe
00000350000C206A    2a  0f8da8e40000   jge 00000350000D0518  <+0xe4d8>

Meaning if the current position is pointing at the very last (16-bit)
character, then we exit the loop. Otherwise we go on and try to find
various matches starting at the current position. However, we can see
in the original expression that any possible match is at least 10
characters (5 astral-plane Unicode values), so we're wasting a lot of
time attempting to find matches in cases where we're too close to the
end of the string for any match to succeed.

This example might be a bit contrived, but I expect that an improvement
in this bounds check would help a larger family of regular expressions,
where the minimum match length is large relative to the string being
matched and we don't meet the other necessary criteria for fast Boyer-
Moore lookahead.

To get the desired bounds check in this case, this patch does the
following:
1. Compute accurate EatsAtLeast values for every node during the
   analysis phase. This could end up doing more work than the current
   implementation, but analysis already has to touch every node, so it
   seems like a cache-friendly time to compute these values. In some
   cases, this might be less total work than the current implementation,
   because the current implementation might recompute the same node
   multiple times.
2. When emitting a quick check, use the EatsAtLeast value from the
   predecessor ChoiceNode for the bounds check.

This improves the UniPoker score on my machine by about 4%, because it
cuts the time spent checking for straights roughly in half, and checking
for straights originally accounted for about 8% of the total time.

Bug: v8:9305
Change-Id: I110b190c2578f73b2263259d5aa5750e921b01be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702125
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62919}
      f42b1a5d
  9. 24 Jul, 2019 1 commit
  11. 19 Jul, 2019 1 commit
    • Sathya Gunasekaran's avatar
      Revert "Reland "[regexp] Call the regexp interpreter without CEntry overhead"" · aa478cac
      Sathya Gunasekaran authored 
      This reverts commit c2ee4a79.

Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
See https://bugs.chromium.org/p/chromium/issues/detail?id=985624

Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}

TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com

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

Bug: v8:8954, chromium:985624
Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62824}
      aa478cac
  13. 18 Jul, 2019 1 commit
    • Patrick Thier's avatar
      Reland "[regexp] Call the regexp interpreter without CEntry overhead" · c2ee4a79
      Patrick Thier authored 
      This is a reland of d4d28b73

Original change's description:
> [regexp] Call the regexp interpreter without CEntry overhead
> 
> Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> 
> This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> 
> Bug: v8:8954
> Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> Commit-Queue: Patrick Thier <pthier@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62753}

Bug: v8:8954
Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#62794}
      c2ee4a79
  15. 17 Jul, 2019 2 commits
  17. 28 May, 2019 1 commit
  19. 27 May, 2019 1 commit
  21. 23 May, 2019 1 commit
  23. 21 May, 2019 2 commits
  25. 20 May, 2019 1 commit
  27. 17 May, 2019 2 commits
  29. 02 May, 2019 1 commit
  31. 29 Apr, 2019 1 commit
  33. 02 Apr, 2019 1 commit
  35. 25 Feb, 2019 1 commit
  37. 05 Feb, 2019 1 commit
  39. 23 Jan, 2019 1 commit
  41. 17 Jan, 2019 2 commits
  43. 08 Jan, 2019 1 commit
  45. 07 Dec, 2018 3 commits
  47. 05 Dec, 2018 1 commit
  49. 27 Nov, 2018 1 commit
  51. 12 Nov, 2018 1 commit
  53. 23 Aug, 2018 2 commits
  55. 09 Apr, 2018 1 commit
  57. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored 
      This reverts commit f9a2e24b.

Reason for revert: gc stress failures not all fixed by follow up.

Original change's description:
> [cleanup] Refactor the Factory
> 
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
> 
> This saves about 20KB of binary size on x64.
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}

TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org

Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored 
      There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.

This saves about 20KB of binary size on x64.

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  59. 09 Mar, 2018 1 commit
  61. 09 Jan, 2018 1 commit