Skip to content

V
V8
Switch branch/tag
  1. 01 Jul, 2019 6 commits
    • Nico Hartmann's avatar
      [js-perf-test] Adds performance benchmarks for BigInt.asUintN · 13debbe1
      Nico Hartmann authored 
      Bug: v8:9213
Change-Id: I05f56f7bdd8d15f2ae992a97529fba18f0644c55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678417
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62461}
      13debbe1
    • Jakob Gruber's avatar
      [regexp] Fix BoyerMooreLookahead behavior at submatches · bc4cbe92
      Jakob Gruber authored 
      Since https://codereview.chromium.org/2777583003, the Boyer-Moore
lookahead (used by the irregexp engine) also looks inside submatches
to narrow down its range of accepted characters at specific offsets.

But the end of a submatch, designated by a PositiveSubmatchSuccess
action node, was not handled correctly. When a submatch terminates,
we have no knowledge of what may follow, and thus must accept any
character at following positions. This is done by the SetRest call
added in this CL.

An example, since this is fairly obscure:

/^.*?Y(((?=B?).)*)Y$/s

The initial non-greedy loop, together with the s flag,
will trigger an attempted Boyer-Moore lookahead. After this follows
an unconditional Y, a *-quantified loop matching any char and
containing a lookahead that matches either 1 B or 0 B's, and an
unconditional trailing Y.

When the BM lookahead scans the subject string for the beginning of
this pattern after the non-greedy loop, it should look for: a Y at
offset 0, and either a B, a Y, or '.' (-> any character) at offset 1.

Prior to this CL this was not the case:

- The lookaround is internally generated as a submatch.
- The optional 'B?' is unrolled into 'either B followed by submatch
  end' or 'submatch end'.
- Filling in BM infos terminates when encountering a submatch end.
  Thus in the former case we added B to the set of accepted characters
  and terminated, while in the latter case we simply terminated.o

This CL ensures that BM will accept any character at any offset at or
exceeding the first encountered submatch end.

Bug: v8:8770
Change-Id: Iff998ba307cd9669203846a9182798b8cf6a85dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679506
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarErik Corry <erikcorry@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62460}
      bc4cbe92
    • Yu Yin's avatar
      [mips64] Correct mjsunit test status. · 91aa3078
      Yu Yin authored 
      regress-976627 is pass and should pass on mips64el,
see 4c156936 https://crrev.com/c/1674027

Change-Id: I4da905ea129a78988d75e5b19cca3a4e5a17fdcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679960
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Yu Yin <xwafish@gmail.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62459}
      91aa3078
    • Leszek Swirski's avatar
      [parser] Mark maybe_assigned recursively for shadowing vars · fc4bcce1
      Leszek Swirski authored 
      The previous fix for this bug (crrev.com/c/1678365) pessimistically
would mark all shadowed variables as maybe_assigned. Unfortunately,
this doesn't work across a parse/preparse boundary, where the shadowing
variable is found via Scope::AnalyzePartially while the shadowed
variable is outside of the preparser entry point. In those cases, the
referencing proxy is copied to the outer scope, in which case the
dynamicness of the original lookup is lost and the maybe_assigned
pessimisation no longer applies.

This means that maybe_assigned status of a variable is dependent on
which function is being parsed. In particular, it can cause bytecode
to change on recompilation, causing issues for lazy source positions.

This patch allows SetMaybeAssigned to walk its shadowed variables,
and recursively set them to maybe_assigned too. Checking for
maybe_assigned changing prevents this recursion from having a
quadratic performance failure mode.

Bug: v8:8510
Bug: v8:9394
Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62458}
      fc4bcce1
    • Z Nguyen-Huu's avatar
      Transition to frozen/sealed elements from Smi/Double elements · 6c61c8aa
      Z Nguyen-Huu authored 
      When applying Object.seal(), Object.freeze() to Smi, Double elements
kind, it will transition to Object elements kind first then to new
frozen, sealed elements kind accordingly.
Also, add more mjsunit.

Bug: v8:6831
Change-Id: I454b42d7eb329b03e20245896641eb6c1a87831d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662657
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62457}
      6c61c8aa
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Serialize source position table" · a7189c43
      Jaroslav Sevcik authored 
      This reverts commit 16c1cb83.

Reason for revert: ClusterFuzz failure

Original change's description:
> [turbofan] Serialize source position table
> 
> ... for concurrent graph building.
> 
> Bug: v8:7790
> Change-Id: I55eb419bda843670eff7de31e942dd8406c792f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682027
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62455}

TBR=jarin@chromium.org,neis@chromium.org,mslekova@chromium.org

Change-Id: Ib8ecd9f4e654b34036ad3157910e19d8ef034c52
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682571Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62456}
      a7189c43
  3. 30 Jun, 2019 2 commits
  5. 29 Jun, 2019 1 commit
  7. 28 Jun, 2019 19 commits
  9. 27 Jun, 2019 12 commits