Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Original-Commit-Position: refs/heads/master@{#42784}
Committed: dc85f4c833
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42800}
This groups together all the promise related runtime functions.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2665983002
Cr-Commit-Position: refs/heads/master@{#42798}
The spec for String.split() requires loading "separator[@@split]".
The KeyedLoadIC for this goes generic right away, but still requires
a runtime call. To avoid that, reshuffle checks in the generic stub
and do the primitive-string -> String-function translation inline.
Review-Url: https://codereview.chromium.org/2654893003
Cr-Commit-Position: refs/heads/master@{#42797}
The existing unit test explicitly checked for this case, but was - under
the right circumstances - defeated by the optimization to not re-run the
whole position search if we were close enough.
BUG=chromium:685618
Review-Url: https://codereview.chromium.org/2663883002
Cr-Commit-Position: refs/heads/master@{#42794}
Port ca8d3ba718
Original Commit Message:
Original commit message:
[wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
Some instructions in WebAssembly trap for some inputs, which means that the
execution is terminated and (at least at the moment) a JavaScript exception is
thrown. Examples for traps are out-of-bounds memory accesses, or integer
divisions by zero.
Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
constant), in addition to the trap condition itself. Additionally, each
WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
number of inputs is linear to the number of trap checks in the function.
Especially for functions with high numbers of trap checks we observe a
significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
a TrapIf common operator only a single node is necessary per trap check, in
addition to the trap condition. Also the nodes which are shared between trap
checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
speedup of 30-50% on average.
This CL only implements TrapIf and TrapUnless on x64. The implementation is also
hidden behind the --wasm-trap-if flag.
Please take a special look at how the source position is transfered from the
instruction selector to the code generator, and at the context that is used for
the runtime call.
R=ahaas@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2666433002
Cr-Commit-Position: refs/heads/master@{#42793}
The bug used to show up when
- we were streaming a script starting with 0xef 0xbb 0xbf
- we aborted preparsing a function (and reset to a bookmark)
BUG=chromium:685618
Review-Url: https://codereview.chromium.org/2663773002
Cr-Commit-Position: refs/heads/master@{#42790}
Reason for revert:
Seems to break layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/13146https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> ValueSerializer: Distinguish between 'undefined' and an absent property.
>
> Dealing with this case requires a wire format change. It is possible that an
> element can be absent even in an array where the dense format was chosen
> (because the array initially had no holes), if the elements are modified while
> they are being serialized. In this case, a new tag for the "hole" is emitted.
>
> The logic to treat undefined in dense arrays as an absent property is restricted
> to versions of the wire format that this tag did not exist.
>
> BUG=chromium:686159,chromium:665820
>
> Review-Url: https://codereview.chromium.org/2660093002
> Cr-Commit-Position: refs/heads/master@{#42784}
> Committed: dc85f4c833TBR=jkummerow@chromium.org,jbroman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2667553003
Cr-Commit-Position: refs/heads/master@{#42788}
Performing lookups on the prototype chain in the stub avoids a
bunch of slow-path runtime calls. For now, only receivers with
dictionary-mode properties do this; fast-mode receivers will follow
if it's beneficial.
(previously landed as r42751 / 82e10f5fba)
Review-Url: https://codereview.chromium.org/2652213003
Cr-Commit-Position: refs/heads/master@{#42785}
Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42784}
When WebAssembly.Table initial size is greater than the declared initial size, table size references should be updated on instantiate for functions to be called at indices greater than the declared initial size.
R=bradnelson@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2661773002
Cr-Commit-Position: refs/heads/master@{#42781}
Without this CL we have only limit for amount of console messages and if user are dumping a huge messages we pretty soon run out of memory.
So let's introduce limit for memory consumption it would help chromium and Node.js as well.
BUG=chromium:671489
R=dgozman@chomium.org,alph@chromium.org, hpayer@chromium.org, ulan@chromium.org
Review-Url: https://codereview.chromium.org/2653293003
Cr-Commit-Position: refs/heads/master@{#42780}
Compiles simply take too long, and such functions are liable to deopt
quickly.
BUG=chromium:686153
Review-Url: https://codereview.chromium.org/2667573002
Cr-Commit-Position: refs/heads/master@{#42779}
Port 93f05b64ae
Original Commit Message:
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5456
LOG=N
Review-Url: https://codereview.chromium.org/2659413002
Cr-Commit-Position: refs/heads/master@{#42778}
The graphs don't show any performance bump for
https://codereview.chromium.org/2659623002, which I do see a much better result for
locally. I suspect the function isn't being optimized in turbofan when the
benchmarks run. Maybe this warmup flag will trigger that.
BUG=v8:5895
Review-Url: https://codereview.chromium.org/2664783002
Cr-Commit-Position: refs/heads/master@{#42776}
We can constant-fold ReferenceEqual(a,b) to false, if the intersection
of the types of a and b is empty. This also repairs a regression in the
RestParameter performance test.
R=petermarshall@chromium.org
BUG=chromium:686668
Review-Url: https://codereview.chromium.org/2666543002
Cr-Commit-Position: refs/heads/master@{#42775}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
Where the arguments have already been inlined, we can replace these calls with a
direct call to construct. We have to make sure that the iteration over the arguments is not observable.
BUG=v8:5895
Review-Url: https://codereview.chromium.org/2659623002
Cr-Commit-Position: refs/heads/master@{#42765}
We need it to be a PropertyCell so that we can list it as a dependency for
optimised code.
Also drive-by clean up some variable names in src/isolate-inl.h.
BUG=v8:5895
Review-Url: https://codereview.chromium.org/2658573008
Cr-Commit-Position: refs/heads/master@{#42764}
This avoids using kTaggedSigned and kTaggedPointer because the
semantic information of those type could be invalid in unreachable
code.
For example, SmiCheck(0.1) has representation TaggedSigned, but it is
later compiled to DeoptimizeUnless(ObjectIsSmi(0.1)) with the constant
0.1 directly connected to the uses. If the use is state-values, which
recorded the TaggedSigned representation of CheckSmi, the code
generator will be confused because it will see constant 0.1 that
claims to be TaggedSigned value.
BUG=chromium:675704
Review-Url: https://codereview.chromium.org/2656243004
Cr-Commit-Position: refs/heads/master@{#42756}
Reason for revert:
Temporarily turn off escape analysis to get a clean canary.
Original issue's description:
> [turbofan] Enable escape analysis.
>
> Review-Url: https://codereview.chromium.org/2626013002
> Cr-Commit-Position: refs/heads/master@{#42229}
> Committed: 30176976e8TBR=tebbi@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2660063002
Cr-Commit-Position: refs/heads/master@{#42755}
Reason for revert:
Speculative revert for breaking a layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/13113
Unfortunately, the test results archive is not giving much info this time.
Original issue's description:
> [stubs] KeyedLoadIC_Generic: prototype chain lookup support
>
> Performing lookups on the prototype chain in the stub avoids a
> bunch of slow-path runtime calls. For now, only receivers with
> dictionary-mode properties do this; fast-mode receivers will follow
> if it's beneficial.
>
> Review-Url: https://codereview.chromium.org/2652213003
> Cr-Commit-Position: refs/heads/master@{#42751}
> Committed: 82e10f5fbaTBR=ishell@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2657393002
Cr-Commit-Position: refs/heads/master@{#42754}
memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
serializing and deserializing long ASCII strings, according to
blink_perf.bindings -- and these are already in a fast path where the entire
string is known to be ASCII (but this has to be checked). The win may be
larger for strings in Latin-1 but not ASCII (though I suspect this is an
uncommon case).
A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
survive wire format version number changes.
This is the first of a series of wire format changes from the previous Blink
format. The deserializer continues to be able to read the old format, but
Chromium M56 will no longer be able to read the messages written by this, in M58.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2658793004
Cr-Commit-Position: refs/heads/master@{#42753}
