Skip to content

V
V8
Switch branch/tag
  1. 30 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce dedicated NewConsString operator. · c061734f
      Benedikt Meurer authored 
      This is in preparation of adding a dedicated StringLength operator that
loads the string length. This way operations on strings don't sit in the
effect chain anymore until the EffectControlLinearizer, which wires them.

The NewConsString semantics could still be better, i.e. it could try to
figure out the proper map instead of going for the CONS_STRING_TYPE
always. But this change is meant to be just about pushing the logic down
to the EffectControlLinearizer, which we didn't have initially when the
ConsString handling was done.

This also allows us to remove the handling of CONS_STRING_TYPE from the
Deoptimizer, since the escape analysis no longer sees cons strings.

Bug: v8:5269, v8:6936, v8:7109, v8:7137
Change-Id: If6c4a6d7cf63a3a3f7a34a920c8e50a94dfa67fa
Reviewed-on: https://chromium-review.googlesource.com/796413
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49729}
      c061734f
  3. 29 Nov, 2017 35 commits
  5. 28 Nov, 2017 4 commits
    • Jeremy Roman's avatar
      Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties. · d3104923
      Jeremy Roman authored 
      The parser holds a single vector whose backing storage is reused in calls
to ParseJsonObject, so that once we reach the peak number of unstored
properties no more allocations are required.

This improves performance of parsing inputs like those in Speedometer VanillaJS
by about 2% in my local measurement, and would presumably do better on more
pathological inputs.

This should also have the side effect of reducing peak memory usage at this time
slightly, since we do fewer zone allocations which cannot be freed until the
parse finishes.

Bug: chromium:771227
Change-Id: I8aa1514b37a74f82539f95f94292c8fa1582d66a
Reviewed-on: https://chromium-review.googlesource.com/789511Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49693}
      d3104923
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] JIT using WasmCodeManager"" · b03b1bd9
      Mircea Trofin authored 
      This reverts commit b301203e.

Reason for revert: Fixed issues on arm.

Original change's description:
> Revert "[wasm] JIT using WasmCodeManager"
> 
> This reverts commit d4c8393c.
> 
> Reason for revert: Breaks ARM hardware:
> https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
> 
> Original change's description:
> > [wasm] JIT using WasmCodeManager
> > 
> > This is the first step towards wasm code sharing. This CL moves wasm
> > code generation outside the JavaScript GC heap using the previously -
> > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
> > flag).
> > 
> > See design document: go/wasm-on-native-heap-stage-1
> > 
> > This CL doesn't change other wasm architectural invariants. We still
> > have per-Isolate wasm code generation, and per-wasm module instance
> > code specialization.
> > 
> > Bug:v8:6876
> > 
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
> > Reviewed-on: https://chromium-review.googlesource.com/674086
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49689}
> 
> TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
> 
> Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6876
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/794690
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49691}

TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: I1b07638d1bb2ba0664305b4b2dcfc1342dc8444f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/794434
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49692}
      b03b1bd9
    • Michael Achenbach's avatar
      Revert "[wasm] JIT using WasmCodeManager" · b301203e
      Michael Achenbach authored 
      This reverts commit d4c8393c.

Reason for revert: Breaks ARM hardware:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268

Original change's description:
> [wasm] JIT using WasmCodeManager
> 
> This is the first step towards wasm code sharing. This CL moves wasm
> code generation outside the JavaScript GC heap using the previously -
> introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
> flag).
> 
> See design document: go/wasm-on-native-heap-stage-1
> 
> This CL doesn't change other wasm architectural invariants. We still
> have per-Isolate wasm code generation, and per-wasm module instance
> code specialization.
> 
> Bug:v8:6876
> 
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
> Reviewed-on: https://chromium-review.googlesource.com/674086
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49689}

TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/794690Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49691}
      b301203e
    • Mike Stanton's avatar
      [Turbofan] Fix incorrect liveness in VisitThrow · 44d71893
      Mike Stanton authored 
      While investigating loop peeling, I found that relatively simple code
like "if (x) { throw new Error('oh hai'); }" in a loop would fail to
peel. The reason is that the call (new Error(...)) was recorded by
loop analysis as being inside the loop but the only usage was in the throw,
which we currently model as being outside of the loop.

We have a regime that inserts LoopExit nodes to mark control exits from
the loops, and LoopExitValues that are meant to mark exiting values.
This wasn't done because of a bug in the bytecode graph builder
VisitThrow() method -- it used the *out* liveness to construct the
appropriate loop exit nodes, and it's more appropriate to use the *in*
liveness.

This addressed the concern. It doesn't fix bug 7099, but is a step on the
way.

Bug: v8:7099
Change-Id: Iaeea794843166063a55c6917e7b0ad4341581261
Reviewed-on: https://chromium-review.googlesource.com/793834Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49690}
      44d71893