This change removes the large contiguous backing store from the young generation
and replaces it regular pages.
We keep a pool of pages that are committed/uncommitted to avoid creating virtual
memory maps during growing and shrinking.
BUG=chromium:581412
LOG=N
Review URL: https://codereview.chromium.org/1853783002
Cr-Commit-Position: refs/heads/master@{#35261}
In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.
In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).
BUG=chromium:599412
LOG=n
Review URL: https://codereview.chromium.org/1857133003
Cr-Commit-Position: refs/heads/master@{#35259}
If we use ScopeIterator inside a debug-evaluate call, we may iterate
over a debug-evaluate context that we created for the debug-evaluate
call. This may trigger assertions.
The solution is to have the ScopeIterator hide debug-evaluate contexts
by unwrapping it if it comes across any.
R=cbruni@chromium.org
BUG=chromium:599662
LOG=N
Review URL: https://codereview.chromium.org/1859033002
Cr-Commit-Position: refs/heads/master@{#35258}
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached
Also fixes a few other places to use AbstractCode.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1854713002
Cr-Commit-Position: refs/heads/master@{#35257}
When seeing a rest pattern, we used to get the remaining elements from the
iterator by calling %concat_iterable_to_array on it. This was wrong because it
caused an observable [[Get]] for @@iterator (which the iterator may not even
provide).
This CL gets rid of the call to %concat_iterable_to_array and does the iteration
manually in a simple while-loop. It also gets rid of %concat_iterable_to_array
itself because there aren't any other uses of it.
BUG=v8:4759
LOG=n
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1852703002
Cr-Commit-Position: refs/heads/master@{#35251}
The CL #35067 (https://codereview.chromium.org/1830703003) exposed one hidden bug in x87 crankshaft code generation for DoMathFloor and DoMathRound.
The current DoMathFloor will change the default round mode of x87 FPU and then deoptimized into FC code before the default x87 FPU's round mode was restored.
This behavior caused several test cases fail as the FC code expected to run under the default x87 FPU's round mode.
This CL fixed this bug.
BUG=
Review URL: https://codereview.chromium.org/1856303002
Cr-Commit-Position: refs/heads/master@{#35250}
Rolling v8/base/trace_event/common to c8c8665c2deaf1cc749d9f8e153256d4f67bf1b8
Rolling v8/build/gyp to 4ec6c4e3a94bd04a6da2858163d40b2429b8aad1
Rolling v8/tools/clang to faee82e064e04e5cbf60cc7327e7a81d2a4557ad
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1856133003
Cr-Commit-Position: refs/heads/master@{#35248}
Mask used in MacroAssembler::TestJSArrayForAllocationMemento was not supposed
to shifted right by 16 bits before loaded in to register r0.
R=michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,joransiu@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1852403002
Cr-Commit-Position: refs/heads/master@{#35247}
The background here is that graphs generated from WASM are not trimmed.
That means there can be some floating control diamonds that are not
reachable from end. An assertion in the scheduler for phis from floating
diamonds checks that the use edge in this situation is the control edge,
but in general, any edge could cause this.
Scheduling still works without this assertion. The longer term fix
is to either trim the graphs (more compile time overhead for WASM)
or improve the scheduler's handling of dead code in the graph. Currently
it does not schedule dead code but the potential use positions of
dead code are used in the computation of the common dominator of uses. We could
recognize dead nodes in PrepareUses() and check in GetBlockForUse()
as per TODO.
R=bradnelson@chromium.org, mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1846933002
Cr-Commit-Position: refs/heads/master@{#35245}
Embedders that passed in non-primitive values should either use
getters/setters (templates) or install a native data property,
otherwise, the values would all result in cross-context leaks
BUG=none
R=verwaest@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1839983002
Cr-Commit-Position: refs/heads/master@{#35244}
The existing FloatFloor/Ceiling functions had an issue with handling
Number.MIN_VALUE (0x1 ==> 5e-324), and would incorrectly return
MIN_VALUE instead of 0/1. Simplify the entire sequence by using the
available hardware instruction with the appropriate rounding mode
(POS_INF for Ceiling, NEG_INF for Floor).
Add missing FIEBRA/FIDBRA cases to disassembler.
R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1853973002
Cr-Commit-Position: refs/heads/master@{#35239}
Run_Wasm_F32CopySign was failing because function copysign
that is used to verify the results does implicit conversion
from float to double. In this conversion we lose information
about NaN sign and the test fails.
Fix by using copysignf to avoid unnecessary float to double
conversion.
TEST=cctest/test-run-wasm/Run_Wasm_F32CopySign
BUG=
Review URL: https://codereview.chromium.org/1857753002
Cr-Commit-Position: refs/heads/master@{#35237}
This fixes a corner case where the generator function of a suspended
generator has been marked for optimization. We assume the optimization
approach will cause a bailout because generators are not optimized. But
resuming is more resilient by always activating the unoptimized code.
R=neis@chromium.org,bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-513471
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1856683002
Cr-Commit-Position: refs/heads/master@{#35234}
The parser uses a try-catch in order to record when the client of an iterator
throws. The exception then used to get rethrown via 'throw', which
unfortunately resulted in the original exception message object getting
overwritten.
This CL solves this as follows:
- add a clear_pending_message flag to TryCatchStatement (set to true in normal
cases),
- set clear_pending_message to false for the TryCatchStatement used in iterator
finalization
- change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
only when the flag is set,
- replace 'throw' with '%ReThrow' in the iterator finalization code, thus
reusing the (not-cleared) pending message
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4875
LOG=n
Review URL: https://codereview.chromium.org/1842953003
Cr-Commit-Position: refs/heads/master@{#35226}
- RegExp.prototype.toString() doesn't have any special handling of
RegExp instances and simply calls the source and flags getters
- Use the original values of global and sticky, rather than based
on the current flag getters, as specified in
https://github.com/tc39/ecma262/pull/494R=yangguo@chromium.org,adamk
LOG=Y
BUG=v8:4602
Review URL: https://codereview.chromium.org/1846303002
Cr-Commit-Position: refs/heads/master@{#35225}
The Chromium 64-bit Windows build uses "Debug_x64" and "Release_x64"
as configs for some reason, so put v8's build config settings there
too.
Reduces e.g. the runtime of CrSettingsBrowserTest.CrSettingsTest from
25s to 12s on my z840 in a 64-bit Chromium debug build
(while also turning on handle zapping).
BUG=chromium:586511
LOG=n
Review URL: https://codereview.chromium.org/1852913002
Cr-Commit-Position: refs/heads/master@{#35224}
Rolling v8/base/trace_event/common to ffb39885a2418caa7a6a6652471fe097732675bd
Rolling v8/tools/clang to 8f7a85a108698ce7ed4fe1aa842efa61f195364e
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1859433002
Cr-Commit-Position: refs/heads/master@{#35223}
Rolling v8/base/trace_event/common to 0fc98828a66ee4d69b9524e4967b9287b7b8eea0
Rolling v8/build/gyp to 697933c2e3b3ffdd6949df3c2fa3613489e01175
Rolling v8/tools/clang to 87058e09f9c547eb5d00cb8ca666c6aec203a117
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1853783004
Cr-Commit-Position: refs/heads/master@{#35219}
port 6df9a22c3f
Original Commit Message:
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
R=verwaest@chromium.org, bmeurer@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1849233003
Cr-Commit-Position: refs/heads/master@{#35217}
Especially when loading and untagging SMIs within code stubs,
instances of the following pattern appear in the generated code:
ld <dst>, <offset>(<base>)
sradi <dst>,<dst>,32
This CL changes that code to:
lwa <dst>, <SmiWordOffset(offset)>(<base>)
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1855533002
Cr-Commit-Position: refs/heads/master@{#35216}
Port 6df9a22c3f
Original commit message:
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1846953006
Cr-Commit-Position: refs/heads/master@{#35214}
