This was suggested by bmeurer after running into the confusing
example of:
x => {x:x}
which might appear to be an arrow function that returns an object
literal containing its argument, but instead is an arrow function
that does nothing.
While it's unclear whether the language would change to make this
probable programmer error an actual syntax error, we can at least
gather some data on the question of whether we see any such code
in the wild.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I08202039ecf7a7a4c71ad95ecd839436b4ec2af8
Reviewed-on: https://chromium-review.googlesource.com/600888
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47171}
In some cases, PreParser cannot replicate the Scope structure created by
Parser. It happens esp. with arrow function parameters, since the relevant
information is already lost by the time we figure out it's an arrow function.
In these cases, PreParser should bail out of trying to create data for skipping
inner functions.
Implementation notes:
- The arrow function case is more fundamental; the non-arrow case could be
hacked together somehow if we implemented tracking is_simple for each param
separately; but now that it's possible to bail out consistently from both
cases, I don't think the is_simple complication is worth it.
- The added mjsunit test cases are based on the test262 test cases which exposed
the problem.
- cctest/preparser/PreParserScopeAnalysis was exercising similar cases, but the
problem didn't show up because the function parameters didn't contain
skippable functions. Those test cases have been repurposed for testing the
bailout.
- Extra precaution: the bailout tests are in a separate file, to guard from the
bug that a bailout case results in bailing out of *all* data creation, which
would make all skipping tests in the same file useless.
BUG=v8:5516
Change-Id: I4324749a5ec602fa5d7dc27647ade0284a6842fe
Reviewed-on: https://chromium-review.googlesource.com/599849
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47170}
And then lower it afterwards. This is more future-proof for
multi-return values.
R=titzer@chromium.org
CC=rossberg@chromium.org
Bug: v8:6672
Change-Id: I6505b049275360c32530992c1db8765254b405c1
Reviewed-on: https://chromium-review.googlesource.com/602036
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47166}
Moves the construction of CompilationInfo for unoptimized code into
GenerateUnoptimizedCode in preparation for making it owned by the
unoptimized compilation jobs (to be done in a followup CL).
This CL also adds a new constructor for creation of unoptimized
CompilationInfos with fields correctly initialized and updates the existing
constructor to he exclusively for optimized compilation. Finally, also moves
the call to RecordFunctionCompilation with LAZY_COMPILE_TAG recording into
FinalizeUnoptimizedCompilationJob where it is called for other unoptimized
compiles.
BUG=v8:5203,v8:6659
Change-Id: Icfd7f56588073f2fc547e002db9fa99843ed2e8b
Reviewed-on: https://chromium-review.googlesource.com/598908
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47160}
This reland is after fix in [heap] Delete wrong DCHECK.
It includes moving ProxyGetProperty to its own stub to reduce
binary size.
This is a reland of 47a97aa53b
Original change's description:
> [builtins] Port getting property from Proxy to CSA
>
> Bug: v8:6559, v8:6557
> Change-Id: If6c51f5483adb73ddd2495cede5d85e887a3c298
> Reviewed-on: https://chromium-review.googlesource.com/589212
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Cr-Commit-Position: refs/heads/master@{#47113}
Bug: v8:6559, v8:6557
Change-Id: I76acd97ba1acb62b7e7983db1741441d997050f0
Reviewed-on: https://chromium-review.googlesource.com/600215
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47159}
Calling the Array constructor is an edge case, and we don't seem to
benefit from doing the AllocationSite tracking there as well. In fact
it's a lot of complexity and somewhat blocking the more important
optimization of the subclass constructors.
This is an attempt to nuke the CallIC support for AllocationSites. If
it regresses something important, we'll have to find another way.
Bug: v8:6399
Change-Id: I56f6da29679c516f0a5c3161c2696fc2b8762176
Reviewed-on: https://chromium-review.googlesource.com/600968
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47158}
In order to limit the overall length of error message, limit the output
of string provided by the user. This is implemented by a helper class
which takes the maximum length as template argument and has simple
accessors for the start address and the length of the truncated string.
This is the compromise CL after
https://chromium-review.googlesource.com/c/566815 and
https://chromium-review.googlesource.com/c/594288.
R=titzer@chromium.org
Bug: chromium:740023, chromium:749041, v8:6634
Change-Id: I7c154eb18b3a6befd5ecabbd2f435b015ad71542
Reviewed-on: https://chromium-review.googlesource.com/600547
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47157}
This fixes a missing fast-path check in the code-stub implementation of
the {Array.prototype.filter} method. Appending to the target JSArray is
only correct if the underlying length did not change.
R=jgruber@chromium.org
TEST=mjsunit/regress/regress-6657
BUG=v8:6657
Change-Id: Ida8d3511485b649b70d9a4b161742d494ebe4dac
Reviewed-on: https://chromium-review.googlesource.com/600467
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47156}
On advancing the iterator we need to reset the current object,
so that it can be lazily reloaded later on.
TBR=mlippautz@chromium.org
Bug: chromium:694255
Change-Id: If7ddd8670df9d11837f491503312919b55b451fe
Reviewed-on: https://chromium-review.googlesource.com/600687
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47142}
Make sure to fail PrepareTransfer when the transferables array contains
a non-ArrayBuffer, otherwise the function leaks a scheduled_exception.
Bug: chromium:736565
Change-Id: I64c2e09eb92720519c7bda2dca41749ff5ac9c8d
Reviewed-on: https://chromium-review.googlesource.com/599357
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47141}
Change-Id: I42f51fd00b1a21a1ff7ef2379fbf81a42266a737
Reviewed-on: https://chromium-review.googlesource.com/599111
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47137}
An optimization in li checks if a value has all their "n" LSBs set to
one, and their "64-n" MSBs set to zero. This is done by checking
base::bits::IsPowerOfTwo(value + 1), but this doesn't cover the case
when only MSB is zero, and other bits are one. Added another check that
covers the missing case, this also fixes Dsubu test.
BUG=
TEST=cctest/test-assembler-mips/Dsubu
Change-Id: I97b8fb4984af3b7f974ba901e3a1a9c89e925805
Reviewed-on: https://chromium-review.googlesource.com/598228
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#47134}
This mitigates the problem of blocking on the main thread when the
platform is unable to execute background tasks in a timely manner.
Bug: v8:6671
Change-Id: I741d4b7594e8d62721dad32cbfb19551ffacd0c3
Reviewed-on: https://chromium-review.googlesource.com/599528
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47126}
For determining whether unaligned memory accessed is allowed, it is
actually sufficient to pass the MachineRepresentation instead of the
MachineType.
As the MachineRepresentation is an enum, this allows to store the set
of unsupported types as an EnumSet instead of std::vector.
R=mstarzinger@chromium.org
Change-Id: Ibe44717bae3a6034bae683057e80bd40d92e70ae
Reviewed-on: https://chromium-review.googlesource.com/598790
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47123}
Don't hold a pointer to parse_info in compilation_info, and instead explicitly
add the fields needed in compiation_info. The intention is to make ParseInfo
only actually needed for parsing, and eventually make it possible to compile
with only a CompileInfo.
BUG=v8:5203
Change-Id: Iecd39245e44c218874401c3991eeaf3ceef2816f
Reviewed-on: https://chromium-review.googlesource.com/595738
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47119}
The {alignment} parameter in {UnalignedLoadSupported} and
{UnalignedStoreSupported} is never being used.
This CL removes it from several interfaces and users.
R=mstarzinger@chromium.org
Change-Id: Iad5a638b7ed358beeed42f0ea7308dc04f1ed23e
Reviewed-on: https://chromium-review.googlesource.com/598788
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47115}
Since frames.h no longer defines basic register types like RegList, it
is no longer necessary to include it in the macro assemblers.
Next step: split out frame-constants.h from frames.h so that it will be
possible to get frame constants without include the stackwalking logic,
which needs objects.h.
R=mstarzinger@chromium.org
Bug:
Change-Id: Ia12d3c8a8d46a73106c3c90bcb4b470c85f1eaa7
Reviewed-on: https://chromium-review.googlesource.com/597788
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47114}
The ScheduledErrorThrower is also needed in the wasm-async fuzzer so I
moved the implementation from wasm-js.cc to wasm-api.[h|cc].
R=clemensh@chromium.org
Bug: chromium:749838
Change-Id: I49d7438d1ec0281285ce0c64ba462c22001be08e
Reviewed-on: https://chromium-review.googlesource.com/591447
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47112}
This removes the obsolete {Crankshaft} factory method as it returns the
same configuration as the {Turbofan} factory by now. We now consistently
use {RegisterConfiguration::Default} everywhere.
R=jkummerow@chromium.org
BUG=v8:6408
Change-Id: I6be25774aa6714ef4dc1ef6856bb6dbc95593a29
Reviewed-on: https://chromium-review.googlesource.com/597858
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47109}
This begins splitting up the Deserializer class into
{Object,Partial,Startup}Deserializer. For now, all functionality remains in
the Deserializer base clase, to be refactored in future CLs. Empty .cc files
are added here to avoid having to touch build files again.
Bug: v8:6624
Change-Id: If563e03492991bd55c91cd2e09312c0a26aaab2c
Reviewed-on: https://chromium-review.googlesource.com/598067
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47107}
Previously TryToName bailed out for Oddball keys (i.e. when passing true
or false as the key), which meant that for example the generic
KeyedLoadIC would always bail out to the %KeyedGetProperty runtime
function. But handling Oddball keys is fairly easy, since every oddball
value carries it's unique string representation. Adding just this case
to the CodeStubAssembler::TryToName method boosts this simple
micro-benchmark by a factor of 4x:
const n = 1e7;
const obj = {};
const key = true;
console.time('foo');
for (let i = 0; i < n; ++i) {
if (obj[key] === undefined) {
obj[key] = key;
}
}
console.timeEnd('foo');
It also shows on the ARES-6 ML benchmark and on several Speedometer
tests, where objects are being used as dictionaries and the developers
rely on the implicit ToString conversions on the property accesses.
In the ARES-6 ML benchmark, the number of calls to %KeyedGetProperty
is reduced by 137,758.
Bug: v8:6278, v8:6344, v8:6670
Change-Id: Iaa965e30be4c247682a67ec09543655df9b761d2
Reviewed-on: https://chromium-review.googlesource.com/599527
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47105}
This is a reland of 470a10015d
Original change's description:
> Start migration of try/throw/catch to match proposal.
>
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
>
> It does the following:
>
> 1) Use exception tags instead of integers.
>
> 2) Only handle empty exception signatures (i.e. no values associated
> with the exception tag.
>
> 3) Only handle one catch clause.
>
> 4) Be sure to rethrow the exception if the exception tag does not match.
>
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
>
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
>
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
>
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}
Bug: v8:6577
Change-Id: I41c3309827c292cb787681a95aaef7cf9b931835
Reviewed-on: https://chromium-review.googlesource.com/598968
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47100}
This behavior has been staged successfully without a bug report, and
has been shipped in the latest versions of Firefox and Safari.
Bug: v8:5070
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I084cae2cc303d6a213bd6789297b91656e162d6b
Reviewed-on: https://chromium-review.googlesource.com/595129
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47098}
If objectGroup is console we should correctly save last evaluated result to expose for next console call in $_ variable.
R=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie0ba2d302606b1c9f096a9a3a107a51a80556c49
Reviewed-on: https://chromium-review.googlesource.com/598936
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47097}
My goal was to move breakpoint API to native with minimal changes around, so on inspector side we use v8::debug::BreakpointId instead of String16, on v8::internal::Debug we use i::BreakPoint object instead of break point object created inside of debug.js.
There are a lot of opportunities how we can improve breakpoints (at least we can avoid some of linear lookups to speedup implementation) but I think that as first step we need to remove mirrors/debug.js APIs.
Drive by: debugger-script.js and usage of debugger context in inspector code base.
R=yangguo@chromium.org,jgruber@chromium.org,clemensh@chromium.org
Bug: v8:5510,chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0b17972c39053dd4989bbe26db2bb0b88ca378f7
Reviewed-on: https://chromium-review.googlesource.com/593156
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47091}
This reverts commit 470a10015d.
Reason for revert: GC stress bot failures.
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/14522
Original change's description:
> Start migration of try/throw/catch to match proposal.
>
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
>
> It does the following:
>
> 1) Use exception tags instead of integers.
>
> 2) Only handle empty exception signatures (i.e. no values associated
> with the exception tag.
>
> 3) Only handle one catch clause.
>
> 4) Be sure to rethrow the exception if the exception tag does not match.
>
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
>
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
>
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
>
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}
TBR=bradnelson@chromium.org,eholk@chromium.org,kschimpf@chromium.org
Change-Id: I01dc8c40cc1057333a988c1d275ce5f457b0cb64
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6577
Reviewed-on: https://chromium-review.googlesource.com/598847
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47090}
This CL does the first baby steps on moving the current (experimental)
exception handling to match that of the WebAssembly proposal.
It does the following:
1) Use exception tags instead of integers.
2) Only handle empty exception signatures (i.e. no values associated
with the exception tag.
3) Only handle one catch clause.
4) Be sure to rethrow the exception if the exception tag does not match.
Note: There are many things that need to be fixed, and are too
numerous to list here. However, the code should have TODO's on each
missing parts of the implementation.
Also note that the code currently doesn't handle nested catch blocks,
nor does it change the throw value being an integer. Rather, the
integer value is still being thrown, and currently is the exception
tag. Therefore, we don't build an exception object. This is the reason
why this CL doesn't handle exceptions that pass values.
Also, the current implementation still can't handle multiple modules
because tag resolution (between) modules has not be implemented yet.
Bug: v8:6577
Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
Reviewed-on: https://chromium-review.googlesource.com/591910
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47087}
They were only limited to 32 bit when using the internal Hashmap. Since
this has changed alreay some time ago, we can switch to 64 bit ids and
check that we never overflow.
Bug:
Change-Id: Ia6c6d02d6b5e555c6941185a79427dc4aa2a1d62
Reviewed-on: https://chromium-review.googlesource.com/598229
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47085}
Consider:
function f() {
return;
}
This CL ensures that the closing brace is considered as covered by
introducing a special case for open-ended range rewrites when the
parent range is the function range itself.
Bug: v8:6000, v8:6661
Change-Id: I0be307759967e9f4df245a4f367326a37dda86fd
Reviewed-on: https://chromium-review.googlesource.com/597651
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47079}
This reverts commit d4a742fdf1.
Reason for revert: gc-stress failures
Original change's description:
> Reland "[heap] Add mechanism for tracking invalidated slots per memory chunk."
>
> This reverts commit c59b81d7b8.
>
> Original change's description:
> > [heap] Add mechanism for tracking invalidated slots per memory chunk.
>
> > For correct slots recording in concurrent marker, we need to resolve
> > the race that happens when
> > 1) the mutator is invalidating slots for double unboxing or string
> > conversions
> > 2) and the concurrent marker is recording these slots.
>
> > This patch adds a data-structure for tracking the invalidated objects.
> > Thus we can allow the concurrent marker to record slots without
> > worrying about clearing them. During old-to-old pointer updating phase
> > we re-check all slots that belong to the invalidated objects.
>
> BUG=chromium:694255
>
> Change-Id: Idf8927d162377a7bbdff34f81a87e52db27d6a9f
> Reviewed-on: https://chromium-review.googlesource.com/596868
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47068}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I81c6059a092cc5834acd799c51fd30dc0ecf5b27
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:694255
Reviewed-on: https://chromium-review.googlesource.com/597787
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47078}
Some bailout reasons are never referenced. Removing these allows us to
decrease the size of bailout reason bit-fields to 7 bits.
Change-Id: Ib5e884d224c12313e06493ed05a18a22b3951665
Reviewed-on: https://chromium-review.googlesource.com/596128
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47077}
This fixes a corner case of rewriting the transition trees, where the
"interesting symbols" bit was not properly forwarded.
Drive-by-fix: Introduce additional checking in Map::ConnectTransition to
make it easier for clusterfuzz to detect cases we might have missed.
R=mstarzinger@chromium.org
Bug: chromium:751109
Change-Id: I3f1a1e6232db9b3694064b3d4e9f37255b018acc
Reviewed-on: https://chromium-review.googlesource.com/597669
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47075}
These tests perform GC manually which does not work well with concurrent
marking and stress incremental marking flags.
BUG=chromium:694255
Change-Id: I43e32957bf37053e0d3af07afa00b8bb40935ebd
Reviewed-on: https://chromium-review.googlesource.com/596887
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47070}
This reverts commit c59b81d7b8.
Original change's description:
> [heap] Add mechanism for tracking invalidated slots per memory chunk.
> For correct slots recording in concurrent marker, we need to resolve
> the race that happens when
> 1) the mutator is invalidating slots for double unboxing or string
> conversions
> 2) and the concurrent marker is recording these slots.
> This patch adds a data-structure for tracking the invalidated objects.
> Thus we can allow the concurrent marker to record slots without
> worrying about clearing them. During old-to-old pointer updating phase
> we re-check all slots that belong to the invalidated objects.
BUG=chromium:694255
Change-Id: Idf8927d162377a7bbdff34f81a87e52db27d6a9f
Reviewed-on: https://chromium-review.googlesource.com/596868
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47068}
This adds support to materialize objects when generating a frame summary
for an optimized frame via {OptimizedFrame::Summarize}. Note that this
means each summary might re-materialize objects and hence produce new
object identities every time. All use sites need to be able to cope with
such semantics.
R=jarin@chromium.org
BUG=v8:6586
Change-Id: I85c66ad3e7d247cd40f37a0a6e4391c0ee279706
Reviewed-on: https://chromium-review.googlesource.com/595745
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47067}
Node.js doesn't have good place to call contextDestroyed.
We need to cleanup everything on our side to allow clients to not call
contextDestroyed method.
R=dgozman@chromium.org,eostroukhov@chromium.com
Bug: none
Change-Id: Ibe3f01fd18afbfa579e5db66ab6f174d5fad7c82
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/575519
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#46849}
Reviewed-on: https://chromium-review.googlesource.com/596549
Cr-Commit-Position: refs/heads/master@{#47060}
This reverts commit eb65f35e96.
Reason for revert: Broke jetstream benchmark on android.
BUG=chromium:750828
Original change's description:
> [wasm] redirect wasm calls to js functions through a GCed table
>
> With this patch, rather than embedding the JSReceiver address directly
> in the WasmToJS wrappers, we put that in a fixed array with global handle
> scope and instead embed the location of the handle and the index in the
> wrapper. This ensures that the wrapper doesn't need to be patched if the
> GC kicks in. This is needed to get the WASM code off the GCed heap.
>
> R=mtrofin@chromium.org
>
> Bug:
> Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
> Reviewed-on: https://chromium-review.googlesource.com/581682
> Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46884}
TBR=mtrofin@chromium.org,aseemgarg@google.com,aseemgarg@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I26f49ee0a1fe73cc5d8852ded87b56638be39ebf
Reviewed-on: https://chromium-review.googlesource.com/596268
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47059}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.orgTBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
This reverts commit 7a5a777c97.
Reason for revert: crashing in test-api
Original change's description:
> [heap] Add mechanism for tracking invalidated slots per memory chunk.
>
> For correct slots recording in concurrent marker, we need to resolve
> the race that happens when
> 1) the mutator is invalidating slots for double unboxing or string
> conversions
> 2) and the concurrent marker is recording these slots.
>
> This patch adds a data-structure for tracking the invalidated objects.
> Thus we can allow the concurrent marker to record slots without
> worrying about clearing them. During old-to-old pointer updating phase
> we re-check all slots that belong to the invalidated objects.
>
> BUG=chromium:694255
>
> Change-Id: Ifc3d82918cd3b96e5a5fb7125691626a56f4ab83
> Reviewed-on: https://chromium-review.googlesource.com/591810
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47049}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I7f4f8e8cb027b921a82e9c0a0623536af02581fb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:694255
Reviewed-on: https://chromium-review.googlesource.com/595994
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47052}
Adds a base class TestPlatform which implements the most common defaults
for v8::Platform methods.
Reworks existing cctests and unittests to use TestPlatform.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifeb28a5a190529697d5bcac227e80b10d454d9bd
Reviewed-on: https://chromium-review.googlesource.com/590194
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47050}
For correct slots recording in concurrent marker, we need to resolve
the race that happens when
1) the mutator is invalidating slots for double unboxing or string
conversions
2) and the concurrent marker is recording these slots.
This patch adds a data-structure for tracking the invalidated objects.
Thus we can allow the concurrent marker to record slots without
worrying about clearing them. During old-to-old pointer updating phase
we re-check all slots that belong to the invalidated objects.
BUG=chromium:694255
Change-Id: Ifc3d82918cd3b96e5a5fb7125691626a56f4ab83
Reviewed-on: https://chromium-review.googlesource.com/591810
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47049}
- rewritten test using new harness,
- removed command line API part since we check it separatelu in inspector/runtime/command-line-api.js
R=jgruber@chromium.org
Bug: none
Change-Id: Ia12cab10a8e299bb17688c9c5f36e7f712aa70ee
Reviewed-on: https://chromium-review.googlesource.com/595032
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47048}
Also fix one apparently-harmless bug in the Parser where we failed
to Finalize an empty scope. Without this fix, the DCHECK fails
on any C-style for-loop with a lexical binding that hits the
fast path (this is well-covered by many existing tests in mjsunit).
Thanks to Georg Neis for the suggestion of this DCHECK.
Change-Id: Ie1a8f8809f4d152c87f2da08209c610514645827
Reviewed-on: https://chromium-review.googlesource.com/587750
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47046}
Remove the concept of IC age from the heap and SFI, since it no
longer does anything useful.
Change-Id: I4ce466efc77c007c09c0889bae09ec6a0c907e33
Reviewed-on: https://chromium-review.googlesource.com/593623
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47041}
The @@toStringTag lookup in Object.prototype.toString causes quite a
lot of overhead and oftentimes dominates the builtin performance. These
lookups are almost always negative, especially for primitive values,
and Object.prototype.toString is often used to implement predicates
(like in Node core or in AngularJS), so having a way to skip the
negative lookup yields big performance gains.
This CL introduces a "MayHaveInterestingSymbols" bit on every map,
which says whether instances with this map may have an interesting
symbol. Currently only @@toStringTag is considered an interesting
symbol, but we can extend that in the future.
In the Object.prototype.toString we can use the interesting symbols
bit to do a quick check on the prototype chain to see if there are
any maps that might have the @@toStringTag, and if not, we can just
immediately return the result, which is very fast because it's derived
from the instance type. This also avoids the ToObject conversions for
primitive values, which is important, since this causes unnecessary
GC traffic and in for example AngularJS, strings are also often probed
via the Object.prototype.toString based predicates.
This boosts Speedometer/AngularJS by over 3% and Speedometer overall
by up to 1%. On the microbenchmark from the similar SpiderMonkey bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=1369042), we go from
roughly 450ms to 70ms, which corresponds to a 6.5x improvement.
```
function f() {
var res = "";
var a = [1, 2, 3];
var toString = Object.prototype.toString;
var t = new Date;
for (var i = 0; i < 5000000; i++)
res = toString.call(a);
print(new Date - t);
return res;
}
f();
```
The design document at https://goo.gl/e8CruQ has some additional
data points.
TBR=ulan@chromium.org
Bug: v8:6654
Change-Id: I31932cf41ecddad079d294e2c322a852af0ed244
Reviewed-on: https://chromium-review.googlesource.com/593620
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47034}
The test TestExportImportedMemoryGrowMultipleInstances in
test/mjsunit/wasm/import-memory.js had a TODO about not taking into
account the maximum size for exported memory objects, thus permitting to
grow past thhe maximum specified in the exported memory object.
The check is already in place at wasm-objects.cc:266
(https://cs.chromium.org/chromium/src/v8/src/wasm/wasm-objects.cc?rcl=a01b55b548add5aec1d3d4d8fcdadfa01555c6ea&l=266).
This CL removes the TODO and asserts that growing past maximum for
exported objects fails.
R=ahaas@chromium.org, gdeepti@chromium.org
Change-Id: Ifa69e4e85e04bc2280b629cebb30d400cca9420f
Reviewed-on: https://chromium-review.googlesource.com/593948
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47029}
This is a reland of 3f90d9f994
Original change's description:
> [Memory] Add an OnCriticalMemoryPressure method to V8::Platform.
>
> Adds virtual V8::Platform::OnCriticalMemoryPressure method, default
> implementation does nothing.
>
> Calls this method on first allocation failures in NewArray, Malloced,
> and zone AccountingAllocator and adds retry logic.
>
> Adds utility functions for allocating base::VirtualMemory to functions
> in allocation.h, which call this method and add retry logic.
>
> Calls these utility functions in heap CodeRange, Spaces, StoreBuffer
> and SequentialMarkingDeque.
>
> Bug: v8:6635
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I38afd394f3be556aca037d16675e9884658158cb
> Reviewed-on: https://chromium-review.googlesource.com/583543
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46988}
Bug: v8:6635
Change-Id: I0d70c5796f407f0ed42cfddf581d26f533f9bea8
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593090
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47027}
The patch changes CallPrinter's AST traversal to continue even after
the first positive match for an AST node. This helps us check for the
subsequent GetIterator AST node in case of destructuring.
We can not differentiate between the function call failing and the
GetIterator failing based on source position info. This would involve
runtime checks costing performance.
Instead of providing an incorrect error, we provide both the
possiblities to user and allow them to disambiguate.
Previously,
d8> function f() { return 5; }
undefined
d8> var [a] = f();
(d8):1: TypeError: f is not a function
var [a] = f();
^
TypeError: f is not a function
at (d8):1:11
Now,
d8> function f() { return 5; }
undefined
d8> var [a] = f();
(d8):1: TypeError: f is not a function or its return value is not iterable
var [a] = f();
^
TypeError: f is not a function or its return value is not iterable
at (d8):1:11
Bug: v8:6616, v8:6513
Change-Id: I3d6427f10cae54951b0ad0e5ddcbe802bb7191c1
Reviewed-on: https://chromium-review.googlesource.com/594894
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47025}
For this testcase to run on BE, it requires Load/store
reversed byte instructions. Disabling testcase until
the necessary instructions are implemented.
R=machenbach@chromium.org, jkummerow@chromium.org
BUG=
LOG=N
Change-Id: I380c9a07030ba12e9b9e81c372496819102e2b0d
Reviewed-on: https://chromium-review.googlesource.com/595047
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47023}
This call from inspector side is redundant, V8 will clear all breakpoints on removing debug delegate in v8::internal::Debug::Unload method.
In any case for correct support of multiclient we need to clear breakpoints in V8DebuggerAgentImpl::disable method.
R=dgozman@chromium.org
Bug: v8:5510,chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I66f9b97797860bad28884a099928d54ac3560428
Reviewed-on: https://chromium-review.googlesource.com/592281
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47022}
This sets the minimum semi-space size to 512K, but does not
change the initial semi-space size.
This reverts commit 774a4c5e24.
Original commit message:
> [heap] Allow a minimum semi-space size of 512K.
> This CL also reduces the minimum semi-space size to 512K.
> BUG=chromium:716032
BUG=chromium:735649
TBR=mlippautz@chromium.org
Change-Id: I1f5dd05b0851ba2b438bedcc023a5cf5f9242a81
Reviewed-on: https://chromium-review.googlesource.com/594107
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47016}
Since any deopt-count-based heuristics should be native context
dependent, it belongs in the feedback vector rather than the SFI.
Bug: v8:6402
Change-Id: I30804d58bc1dec9150558e6ee21ee5b4dbd36c8d
Reviewed-on: https://chromium-review.googlesource.com/593661
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47014}
This reverts commit 409f84c93b.
Reason for revert: Breaks nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288
Original change's description:
> [async-iteration] implement spec-change to `yield` in async generators
>
> Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
>
> AsyncGeneratorResolve no longer unwraps a value component. Instead, the
> value is unwrapped before the builtin call via Await, allowing Promise
> rejections to affect the generator control flow.
>
> Thus, all `yield <expr>` implicitly become `yield await <expr>`.
>
> Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
> the generator is resumed with `.return()`, the parameter passed to .return()
> is awaited before generator execution properly continues).
>
> BUG=v8:5855
> R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
> Reviewed-on: https://chromium-review.googlesource.com/523844
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47011}
TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com
Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5855
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593952
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47013}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the
value is unwrapped before the builtin call via Await, allowing Promise
rejections to affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
the generator is resumed with `.return()`, the parameter passed to .return()
is awaited before generator execution properly continues).
BUG=v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
Reviewed-on: https://chromium-review.googlesource.com/523844
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47011}
Instead of auto-generating the Name() convenience accessor, use a macro to
avoid wasting code space.
BUILTIN_CODE(isolate, Name)
expands to
isolate->builtins()->builtin_handle(Builtins::kName);
This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
Reviewed-on: https://chromium-review.googlesource.com/593607
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47010}
Remove opt_count from SFI, which only had two real uses:
1. Detecting OSR in tests -- replaced with a stack walk in
%GetOptimizationStatus
2. Naming optimization log files -- replaced with the
optimization id
This allows us to remove a field from the SFI, moving the
bailout reason into the counters field.
As a drive-by, add optimization marker information (e.g.
marked for optimization) to the optimization status.
Change-Id: Id77deb5dd5439dfba058a7e1e1748de26b717d0d
Reviewed-on: https://chromium-review.googlesource.com/592028
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47009}
This reverts commit 072d0e3eb6.
Reason for revert: Performance regressions (https://crbug.com/749041).
Original change's description:
> [wasm] Allow for arbitrarily long error messages
>
> We currently have a fixed limit of 256 characters for error messages
> generated in the decoder. However, we sometimes embed names in it,
> which makes it easy to generate a crash by using long names (e.g. for
> exports) in invalid wasm modules.
> This CL fixes this by switching to a stream based interface, allowing
> to pass arbitrary objects to be printed. With this interface, we can
> easily limit the length of output later.
>
> R=titzer@chromium.org
>
> Bug: chromium:740023
> Change-Id: I2848c31c63a015157e2a3a9458b54e523060cd69
> Reviewed-on: https://chromium-review.googlesource.com/565282
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46860}
TBR=titzer@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:740023, chromium:749041
Change-Id: I005a60d55dcf01d350230f8d98f715bab9c43886
Reviewed-on: https://chromium-review.googlesource.com/593807
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47008}
Print AST needs access to the internalized strings, so make sure AST
is internalized before we print it.
BUG=v8:5203
Change-Id: Ia4995147feb7ec466523a0c4a89620749b23dcab
Reviewed-on: https://chromium-review.googlesource.com/593648
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47006}
Function-granularity coverage skips functions that are both uncovered
and have an uncovered parent. This optimization needs to be tweaked once
block coverage and incremental collection is in play, as it is possible
to have a function with invocation_count == 0 (i.e. uncovered at
function granularity) that still has relevant block-granularity
coverage.
Bug: v8:6000
Change-Id: I4cc81b8a6935aa58e29d383ed4fa749cbfe69352
Reviewed-on: https://chromium-review.googlesource.com/589508
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46991}
Adds virtual V8::Platform::OnCriticalMemoryPressure method, default
implementation does nothing.
Calls this method on first allocation failures in NewArray, Malloced,
and zone AccountingAllocator and adds retry logic.
Adds utility functions for allocating base::VirtualMemory to functions
in allocation.h, which call this method and add retry logic.
Calls these utility functions in heap CodeRange, Spaces, StoreBuffer
and SequentialMarkingDeque.
Bug: v8:6635
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I38afd394f3be556aca037d16675e9884658158cb
Reviewed-on: https://chromium-review.googlesource.com/583543
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46988}
To avoid using debugging context and debugger-script.js on inspector side we can move SetScriptSource call to v8::internal::Debug. Theoretically we can move live edit implementation to native completely but since it will be reimplemented it looks redundant.
R=yangguo@chromium.org,jgruber@chromium.org
Bug: chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id09492c2d2a93efbde429c9cc1bc181d5fdda19b
Reviewed-on: https://chromium-review.googlesource.com/590736
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46985}
This reverts commit 176a2b24fb.
Reason for revert: performance regression on the benchmarks.
Original change's description:
> [heap] Reland "[heap] Allow a minimum semi-space size of 512K."
>
> This patch changes the semi-space size to 512K.
>
> > Original commit message:
> > Revert "[heap] Allow a minimum semi-space size of 512K."
> > This reverts commit 0d2ed6c328.
> > The CL introduced perf regressions: crbug.com/735649.
> > We are going to reland the CL in an isolated V8 roll to ensure
> > that perf regressions are attributed correctly.
>
> > Original commit message:
> > > [heap] Allow a minimum semi-space size of 512K.
> > > This CL also reduces the minimum semi-space size to 512K.
> > > BUG=chromium:716032
> > BUG=chromium:735649
>
> Change-Id: Iabc377cba2911b28d51b98bb5b85134d4e893632
> Reviewed-on: https://chromium-review.googlesource.com/575066
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46763}
TBR=ulan@chromium.org,mlippautz@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I80f8b6699f41e91512f7cec38060c829252ff95e
Reviewed-on: https://chromium-review.googlesource.com/591309
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46982}
in preparation for caching StoreIC-Transition handlers in there.
This CL should not change behavior or performance.
The TransitionArray class no longer serves a dual purpose; it is now
simply the data structure serving that role. Further, it now supports
storing transitioning handlers in its "target" slot, which in turn have
a WeakCell pointing to the transition target (but this functionality
is not being used yet).
The interface for accessing a map's transitions, previously implemented
as a set of static functions, is now handled by the TransitionsAccessor
class. It distinguishes the following internal states:
- kPrototypeInfo: map is a prototype map, will never cache any transitions.
- kUninitialized: map can cache transitions, but doesn't have any.
- kWeakCell: map caches a single transition, stored inline. Formerly known
as "IsSimpleTransition".
- kFullTransitionArray: map uses a TransitionArray to store transitions.
- kTuple3Handler, kFixedArrayHandler: to be used in the future for caching
transitioning handlers.
Change-Id: If2aa68390981f96f317b958445a6e0b935c2a14e
Reviewed-on: https://chromium-review.googlesource.com/550118
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46981}
Add UseScratchRegisterScope for MIPS and use it instead of using at register directly.
Original commit message:
`Introduce a stripped down version of UseScratchRegisterScope for ARM and use it
inside the assembler and macro-assembler. At the exception of the Call
instructions, we now use this scope instead of using the ip register
directly. This is inspired from how the ARM64 backend works.
In general, the benefit of doing this is we can catch cases where ip is being
used both by the caller and by the assembler. But more specifically, TurboFan
reserves r9 as an extra scratch register because ip can already be used by the
assembler. With this utility, we can isolate the cases in the code generator
which need an extra register and potentially fix them, allowing us to give r9
back to the register allocator.
This patch uncovered places in the assembler where we were using ip
unconditionally when we could have re-used the destination register instead.`
Bug:
Change-Id: I1a35c1661579882801605337abfc95f75b47f052
Reviewed-on: https://chromium-review.googlesource.com/574923
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46963}
Rather than storing the isolate in compiler dispatcher jobs, which gets
weird for jobs that are entirely off-thread, instead pass the isolate
in when stepping on the main thread.
This makes it clearer which steps must be executed on the main thread,
as they require the caller to explicitly give them access to the
isolate.
Bug: v8:6537
Change-Id: I02fff7c77fdcdbfb099a38235f94d8c1040699ac
Reviewed-on: https://chromium-review.googlesource.com/589437
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46962}
With TurboFan, there should no longer be any deopt loops (aside from
bugs). So, the "too many deopts" bailout is no longer needed, at least
in its current form.
This fixes an issue where deopt counts are leaked between native
contexts, resulting in optimization being disabled unnecessarily.
Bug: v8:6402
Change-Id: Ia06374ae6b5c2d473bcdd8eef1284bf02766c2fb
Reviewed-on: https://chromium-review.googlesource.com/588894
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46961}
This includes the catch and finally keywords in the respective range.
For instance:
// Catch range previously: |<--------->|
try { /* ... */ } catch (e) { /* ... */ }
// Now: |<------------------->|
Bug: v8:6000
Change-Id: I1bd9f7fce8bb7de945da83ab512833841b9d956a
Reviewed-on: https://chromium-review.googlesource.com/586598
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46959}
Everything inside a class lives inside the class scope, so
reparenting the class scope is the only operation that
should be done to ClassLiterals during reparenting.
Bug: chromium:740591
Change-Id: Ia5b96b44ff1ca6cfa274effb5a04651809bab9bd
Reviewed-on: https://chromium-review.googlesource.com/588054
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46951}
The approach to creating compiler dispatcher jobs for inner functions after
they had been parsed didn't provide the startup benifits we hoped for due
to the need to hold onto the whole zone memory AST while waiting for the
jobs to complete.
This CL removes the ability to create these compilation jobs (which was never
enabled by default anyway). Going forward we will potentially use the
parser task approach to parse+compile inner functions in their own job.
BUG=v8:5203
Change-Id: I63134746aa23b4aa6e3bfa17c539954890fd9b0f
Reviewed-on: https://chromium-review.googlesource.com/590007
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46948}
This CL moves us much closer to the point where we can remove debugger-script.js and usage of debugger context from inspector.
There are three main parts left:
- managing breakpoints,
- inspecting stack and scopes (this CL),
- LiveEdit.
In this CL I moved all stack/scope inspection to native. As side effect running debugger and inspector tests are 10-20% faster (it's significant since not all of tests requesting break).
R=yangguo@chromium.org,jgruber@chromium.org
Bug: chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I409396a687e18e9c0554c0c9c35b6e1064627be8
Reviewed-on: https://chromium-review.googlesource.com/580645
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46947}
These counters handle cases in which the catch/finally block contains a jump
statement.
Bug: v8:6000
Change-Id: Ic83f11ee431edabe61f129c9abc3adc12a79c338
Reviewed-on: https://chromium-review.googlesource.com/586595
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46945}
We must ensure required root objects will be filled when such
objects will be deserialized.
Change-Id: I25136d31cb2e0c0a69a51c5635192f17bbe2a9ba
Reviewed-on: https://chromium-review.googlesource.com/579768
Commit-Queue: Vyacheslav Chigrin <vchigrin@yandex-team.ru>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46944}
We've been passing a context to the compiler, which turns out to be
solely used to determine if we're executing in a specific cctest configuration.
This change adds a configuration to the graph builder that we can use to
explicitly opt out of stack checks and traps. CcTests default to opting out,
except for the few that don't.
Bug:
Change-Id: I4724e31c2a62e9b3ab4feadb788287c374b39f53
Reviewed-on: https://chromium-review.googlesource.com/585779
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46943}
This fixes the second-order Array.prototype function {forEach} and {map}
to now perform a callability check of the given callback function. For
empty arrays it is observable whether such a check outside the loop has
been elided or not.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-747062
BUG=chromium:747062
Change-Id: I1bbe7f44b3b3d18e9b41ad0436975434adf84321
Reviewed-on: https://chromium-review.googlesource.com/588893
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46942}
Reland of https://chromium-review.googlesource.com/c/558290/
Makes compiler dispatcher jobs an abstract interface, with unoptimized
compile jobs as an implementation of this interface.
Bug: v8:6537
Change-Id: Ia85781f72c7aaca497896ca4efa91ada97e43b1c
Reviewed-on: https://chromium-review.googlesource.com/589154
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46940}
In the process, cleanup some of the maths and functionality used to setup
descriptors and compute parameters. Also cleanup and correct the context
passing.
Change-Id: I6b6629bc81ef1c03425332dd6eadf3085efec7c9
Reviewed-on: https://chromium-review.googlesource.com/588892
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46938}
Note that this also renames the existing "asm_wasm" variant to use the
more appropriate "stress_asm_wasm" name.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I1f9550cd03874c678f4583047a4e123a6f090250
Reviewed-on: https://chromium-review.googlesource.com/584879
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46937}
Instead of having feedback vector as a subtype of FixedArray with
reserved slots, make it a first-class variable-sized object with a
fixed-size header. This allows us to compress counters to ints in the
header, rather than forcing them to be Smis.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48
Reviewed-on: https://chromium-review.googlesource.com/585129
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46935}
Test mjsunit/optimized-map walked an array through different
ElementsKind transitions, but it failed to verify that the
expected ElementsKind was in place. Although we have a regression
test for the bug, it's a good idea to make sure the basic
test covers all paths.
Bug: chromium:747075
Change-Id: I1424880801857f3356bfd63839d351d6fd1521e0
Reviewed-on: https://chromium-review.googlesource.com/584837
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46933}
Makes compiler dispatcher jobs an abstract interface, with unoptimized
compile jobs as an implementation of this interface.
Bug: v8:6537
Change-Id: I6569060a89c92d35e4bc7962623f77082a354934
Reviewed-on: https://chromium-review.googlesource.com/558290
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46931}
Adding (very) small tests for deoptimization.
Some of these tests were failing when the safepoints were not found,
after setting the return address.
BUG=V8:6563
Change-Id: I3af36b193a5982cd73414cc1884c5f0a7a727f5a
Reviewed-on: https://chromium-review.googlesource.com/584751
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#46922}
This reverts commit 862d605c13.
Reason for revert: fixed compile issue
Original change's description:
> Revert "[wasm] Consolidate function table representation."
>
> This reverts commit 4a45f35f26.
>
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/25471
>
> Original change's description:
> > [wasm] Consolidate function table representation.
> >
> > This CL avoids the need to reference the function tables (and signatures)
> > as either fixed arrays or vectors, preferring vectors.
> >
> > The only place we need fixed arrays is on the compiled module, to support
> > serialization. When we move off the GC heap, we'll also move away
> > from fixed arrays in that last case.
> >
> > The CL aids with getting wasm of the GC heap, by reducing the places
> > and representations we'll need to change when changing the way we
> > reference fixed tables.
> >
> > Bug:
> > Change-Id: Id4e43905a3df39062bf2839fa72dd5d9a0fe87da
> > Reviewed-on: https://chromium-review.googlesource.com/588334
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46917}
>
> TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: Ie7d04f7ec74d6d0b3783df1c78c91c100ab784f4
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/588627
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46918}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: Ic0ba8097c13f2b1afd263b6243360e8ab95ae474
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/588667
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46919}
This reverts commit 4a45f35f26.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/25471
Original change's description:
> [wasm] Consolidate function table representation.
>
> This CL avoids the need to reference the function tables (and signatures)
> as either fixed arrays or vectors, preferring vectors.
>
> The only place we need fixed arrays is on the compiled module, to support
> serialization. When we move off the GC heap, we'll also move away
> from fixed arrays in that last case.
>
> The CL aids with getting wasm of the GC heap, by reducing the places
> and representations we'll need to change when changing the way we
> reference fixed tables.
>
> Bug:
> Change-Id: Id4e43905a3df39062bf2839fa72dd5d9a0fe87da
> Reviewed-on: https://chromium-review.googlesource.com/588334
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46917}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: Ie7d04f7ec74d6d0b3783df1c78c91c100ab784f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/588627
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46918}
This CL avoids the need to reference the function tables (and signatures)
as either fixed arrays or vectors, preferring vectors.
The only place we need fixed arrays is on the compiled module, to support
serialization. When we move off the GC heap, we'll also move away
from fixed arrays in that last case.
The CL aids with getting wasm of the GC heap, by reducing the places
and representations we'll need to change when changing the way we
reference fixed tables.
Bug:
Change-Id: Id4e43905a3df39062bf2839fa72dd5d9a0fe87da
Reviewed-on: https://chromium-review.googlesource.com/588334
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46917}
- No need for multiple assertAsyncRan() calls, just do t.plan(count)
- Previously, if you forget to call assertAsyncRan(), the test will still
pass, which is no longer true.
- No longer hold global state (with
asyncAssertsExpected). Previously if one assert wasn't hit then
there's no way to find out which test failed. You'd have to
comment each test and try again.
- Each test runs independently in the microtask queue.
- Better failure reporting by printing the entire function.
Example error :
=== mjsunit/harmony/promise-prototype-finally ===
abort: Expected asserts: 2, Actual asserts: 1
in test: reject/finally/then
assert => {
assert.plan(2);
Promise.reject(3).finally().then(
assert.unreachable,
x => {
assert.equals(3, x);
});
}
Change-Id: Ic3f6272e1e87b8b0121b8c8c7cce19cf90d1f1be
Reviewed-on: https://chromium-review.googlesource.com/455555
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46910}
Moves parser internalization of ast values out of
ParseAny/Program/Function and instead internalizes during compile
finalization. Currently also internalizes during scope analysis if
there is a ScopeInfo to enable variable name lookups. We also
internalize early for FCG / AstGraphBuilder.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia766795947d847517b87cd5ea39797347083174b
Reviewed-on: https://chromium-review.googlesource.com/582407
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46904}
Reland of https://chromium-review.googlesource.com/c/543042/.
Now the OSR phase is only used when OSRing from the ast graph builder.
When OSRing from Turbofan, the implementation is now in the graph
building phase, at the beginning of the VisitBytecode function.
We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
nor nodes for the possible code of the OSRed function which is before
the OSRed loops.
The trimming and reducing of the OSR phase is not done either. This
change in the way the way the OSR is done enabled to remove the
workaround to the bug mentioned below.
Bug: v8:6112
Bug: v8:6518
Change-Id: Ia02f2138f54fc79cab2f02fed68d9bb522d6ce14
Reviewed-on: https://chromium-review.googlesource.com/584756
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46899}
Previously we would shift the length of the string by three, which
could overflow with the new larger string length limit. Now we check
that the length will fit without extra allocation before and after
the shift, because really large strings will never fit, and will
always go to the Checked case.
Bug: chromium:748069, v8:6148
Change-Id: I41cac14b0fde6c5e8ca92305a052cbb743111554
Reviewed-on: https://chromium-review.googlesource.com/584611
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46896}
This brings the wasm-constants.js file inline with that (forked copy) in
the WebAssembly spec repo, which should make it easier to export tests
from V8 to the spec in the future.
R=clemensh@chromium.org
Bug:
Change-Id: I7db23efc2d671f65b614f9dbc97ae2f355f91b04
Reviewed-on: https://chromium-review.googlesource.com/586248
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46894}
The yield* statement when used in combination with async iterators is not
supported yet, as that is desugared into a more complex construct that doesn't
offer a good dedicated bytecode to attach the source range information yet.
Note that invocation counts of generator functions are incorrect as they count
each resumption as an individual call. See https://crbug.com/v8/6594.
Bug: v8:6000
Change-Id: I7ac7073473c9b64bb207cdbc4dab083ec1145656
Reviewed-on: https://chromium-review.googlesource.com/582690
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46890}
Refactor common test code into code-coverage-utils.js and add tests to
verify counter behavior in opt/no-opt situations.
Bug: v8:6000
Change-Id: I07e62345476e8c81521c491ae605ddaf71600667
Reviewed-on: https://chromium-review.googlesource.com/584449
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46888}
Before we try to do ASI and fail with a generic error, we special case
for the await token in the failure case.
Bug: v8:6572, v8:6513
Change-Id: Ia050c98b5a5b20bc326f429a367635b8553e4112
Reviewed-on: https://chromium-review.googlesource.com/582210
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46885}
With this patch, rather than embedding the JSReceiver address directly
in the WasmToJS wrappers, we put that in a fixed array with global handle
scope and instead embed the location of the handle and the index in the
wrapper. This ensures that the wrapper doesn't need to be patched if the
GC kicks in. This is needed to get the WASM code off the GCed heap.
R=mtrofin@chromium.org
Bug:
Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
Reviewed-on: https://chromium-review.googlesource.com/581682
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46884}
Remove need for shuffling of accumulator and operand registers when
suspending a generator
BUG=v8:6351
TBR=bmeurer@chromium.org
Change-Id: I372509adc03b9781716412b809639554fe16e372
Reviewed-on: https://chromium-review.googlesource.com/578377
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46883}
Bug: chromium:740591
Change-Id: I869be41d8630b23704b9470c4d3db8a21bbde873
Reviewed-on: https://chromium-review.googlesource.com/583531
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46881}
The manual monthly update of the wasm spec tests.
R=rossberg@chromium.org
Change-Id: I7d30750f18d6b4e53bbb59e24e040b1bd87d7eba
Reviewed-on: https://chromium-review.googlesource.com/584750
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46877}
Empty Array literals are amongst the most commonly used literal types on our
top25 page list. Using a custom bytecode we can drop the boilerplate for empty
Array literals alltogether. However, we still need a proper AllocationSite to
track ElementsKind transitions.
Bug: v8:6211, chromium:746935
Change-Id: I891eaa778e4e81e138e483a65f04ae00ae30bd28
Reviewed-on: https://chromium-review.googlesource.com/580932
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46875}
This must throw for uninitialized properties.
R=adamk@chromium.org
Bug: v8:1569, v8:5487
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I8beb8bf6a197870eb5c038102ab474dd12f6b6eb
Reviewed-on: https://chromium-review.googlesource.com/582013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46870}
Reland of https://chromium-review.googlesource.com/c/544888/.
Instead of counting profiler ticks on the shared function info (which is
shared between native contexts), count them on the feedback vector
(which is not). This allows us to continue pushing optimization
decisions off the SFI, onto the feedback vector.
Note that a side-effect of this is that ICs don't have to walk the stack
to reset profiler ticks, as they can access the feedback vector directly
from their feedback nexus.
Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48
Reviewed-on: https://chromium-review.googlesource.com/579051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46868}
This reverts commit 87aae715df.
Reason for revert: Speculative revert because of ASAN leaks in https://chromium-review.googlesource.com/584488
Original change's description:
> [inspector] support for cases when embedder doesn't call contextDestroyed
>
> Node.js doesn't have good place to call contextDestroyed.
> We need to cleanup everything on our side to allow clients to not call
> contextDestroyed method.
>
> R=dgozman@chromium.org,eostroukhov@google.com
>
> Bug: none
> Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6bfd4d6039f53eb994a2d20ecbca650744564e29
> Reviewed-on: https://chromium-review.googlesource.com/575519
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46849}
TBR=dgozman@chromium.org,kozyatinskiy@chromium.org,eostroukhov@google.com,eostroukhov@chromium.org
Change-Id: Ic3c2764159f809536670f73ab0cd5ea37317d400
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/584767
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46865}
This reverts commit 8580529302.
Reason for revert: increased memory usage on benchmarks.
BUG=chromium:747806
Original change's description:
> [heap] Remove clearing of caches and counter of shared function info in
> marking visitors.
>
> This makes incremental and concurrent visitors of share function infos
> side-effect free.
>
> BUG=chromium:694255
>
> Change-Id: I85ee7bac17f17bdbc101ef64ecfb46020b5b3458
> Reviewed-on: https://chromium-review.googlesource.com/574851
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46796}
TBR=ulan@chromium.org,mlippautz@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:694255
Change-Id: Id28551ce8378820b0272721b7efb388727c442d4
Reviewed-on: https://chromium-review.googlesource.com/584288
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46864}
Move ScopeInfo allocation out of DeclarationScope::Analyse and do it later
in the compile when finalizing unoptimized code generation. This is to enable
scope analysis to be done without heap allocation so it could run off-thread.
BUG=v8:5203
Change-Id: I954aacd4353925bbbd5a940d979027de2c52e1fd
Reviewed-on: https://chromium-review.googlesource.com/581108
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46862}
This is so that we can distinguish hash tables by instance type. We can
then introduce maps for each kind of hash tables to further distinguish.
R=mstarzinger@chromium.org
Bug: v8:6593
Change-Id: Ice9e6bb7b85d825207ac489b6930ac9020d60db8
Reviewed-on: https://chromium-review.googlesource.com/582814
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46861}
We currently have a fixed limit of 256 characters for error messages
generated in the decoder. However, we sometimes embed names in it,
which makes it easy to generate a crash by using long names (e.g. for
exports) in invalid wasm modules.
This CL fixes this by switching to a stream based interface, allowing
to pass arbitrary objects to be printed. With this interface, we can
easily limit the length of output later.
R=titzer@chromium.org
Bug: chromium:740023
Change-Id: I2848c31c63a015157e2a3a9458b54e523060cd69
Reviewed-on: https://chromium-review.googlesource.com/565282
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46860}
Add a third parameter to {AsHex} which specifies whether the prefix
"0x" should be printed. Also, add the {AsHexBytes} helper which
outputs the hex number as individual bytes separated by a whitespace.
Also add unit tests for both helpers.
Both helper will be used in an upcoming refactoring of wasm error
messages:
https://chromium-review.googlesource.com/c/565282R=titzer@chromium.org
Change-Id: I42d5ace9841ffb918cb4d6803b6347229e446097
Reviewed-on: https://chromium-review.googlesource.com/583448
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46859}
Extend the errors.js mjsunit test to also check for the message in the
generated errors. This will help catch bugs later, e.g. when
refactoring the way we output errors:
https://chromium-review.googlesource.com/c/565282
Drive-by 1: Fix a superfluous period in one error message.
Drive-by 2: Fix a weird exception catching construct in the test.
R=titzer@chromium.org
Change-Id: I1c2e92fb2c34a481cbf8802153f8502452d45348
Reviewed-on: https://chromium-review.googlesource.com/582960
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46858}
The second f1 function would overwrite the first, breaking all tests
that were intended to use the first f1 definition.
Bug:
Change-Id: I79dd1ae344ebf3cf08991d550983f1b01274b352
Reviewed-on: https://chromium-review.googlesource.com/581528
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46856}
A Phi is necessary to carry the ElementsKind forward in case transitions
are taken.
Bug: chromium:747075
Change-Id: I9d9d66b0219fe3f67d08536f4d478ee300c76acb
Reviewed-on: https://chromium-review.googlesource.com/583090
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46852}
This CL adds support for ArrayBuffer and SharedArrayBuffer subtypes for injected
script source. It also adds the byteLength/size to the description of these
objects and for the upcoming "blob" subtype when appropriate.
This is dependent on a DevTools frontend patch to accept these new subtypes:
https://chromium-review.googlesource.com/c/582427/
Bug: chromium:653620
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If8f612b54e82e6fd2f056545bd521868ba7349fd
Reviewed-on: https://chromium-review.googlesource.com/582233
Commit-Queue: Erik Luo <luoe@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46851}
Node.js doesn't have good place to call contextDestroyed.
We need to cleanup everything on our side to allow clients to not call
contextDestroyed method.
R=dgozman@chromium.org,eostroukhov@google.com
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6bfd4d6039f53eb994a2d20ecbca650744564e29
Reviewed-on: https://chromium-review.googlesource.com/575519
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46849}
This reverts commit 3d023952f2.
Reason for revert: breaks gcc build
Original change's description:
> [runtime] Make JSFunction::prototype_or_initial_map field optional.
>
> Functions that don't have prototype need to store neither prototype nor
> initial map, so the |prototype_or_initial_map| field is not required for
> such maps.
>
> Bug: v8:6459
> Change-Id: I4b3066bd6a4fed42c19f217bae82a8bce552bdca
> Reviewed-on: https://chromium-review.googlesource.com/570250
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46840}
TBR=jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org
Change-Id: Ie9951c87b15c8bd365ed187d7f719b8f08dd0bb5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6459
Reviewed-on: https://chromium-review.googlesource.com/583088
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46841}
Functions that don't have prototype need to store neither prototype nor
initial map, so the |prototype_or_initial_map| field is not required for
such maps.
Bug: v8:6459
Change-Id: I4b3066bd6a4fed42c19f217bae82a8bce552bdca
Reviewed-on: https://chromium-review.googlesource.com/570250
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46840}
Now that literal allocation is inlined, it is possible to optimize out regexp
literal allocation completely. If a lazy deopt is triggered in that situation,
the deoptimizer needs to know how to materialize regexp objects.
Bug: v8:6605,v8:6556,chromium:747825
Change-Id: Id491053f8e64fec16540efbfdc6c7c524da3e080
Reviewed-on: https://chromium-review.googlesource.com/582609
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46837}
This adds handling for exceptional control projections when lowering
calls to {Array.prototype.forEach} in the call reducer.
R=jarin@chromium.org
TEST=mjsunit/optimized-foreach
BUG=v8:1956
Change-Id: I282048b203814cbc1c90df983879578b210f92fb
Reviewed-on: https://chromium-review.googlesource.com/574542
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46834}
This reverts commit 990dd947bc.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Introduce HASH_TABLE_TYPE instance type.
>
> This is so that we can distinguish hash tables by instance type. We can
> then introduce maps for each kind of hash tables to further distinguish.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:6593
> Change-Id: I1a532884758e571abdfe2e2743fc5ea611d12f7e
> Reviewed-on: https://chromium-review.googlesource.com/581009
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46828}
TBR=yangguo@chromium.org,mstarzinger@chromium.org
Change-Id: Ia47d408e5cf47983940227b4cc445a704d7f8d19
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6593
Reviewed-on: https://chromium-review.googlesource.com/581493
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46833}
Properly hook up the (existing) IC slots for the CallWithSpread and
ConstructWithSpread bytecodes, and change the interpreter to collect
feedback (call counts and regular target function feedback) for those.
There's no integration with the Array constructor yet, since that
requires some yak shaving to thread through the AllocationSite to the
Array constructor stub. Once we have a solution for that, we can also
remove the current code duplication in the Call/Construct IC logic.
Also properly hook up the newly available feedback in TurboFan. This
will fix not only the missing target feedback, but more importantly
the tear-up decisions for optimization are correct now in the presence
of spread calls, and even more importantly the inlining heurstic has
proper call frequencies for those.
Some follow-up changes will be necessary to make sure we use the
feedback even for corner cases that aren't handled properly yet. Also
we should consider collecting feedback about the map of the spread
at some point to be able to always inline the spread calls.
Bug: v8:6399, v8:6527, v8:6630
Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00
Reviewed-on: https://chromium-review.googlesource.com/582647
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46832}
... in order to avoid the need to update field types through elements
kind transitions.
Bug: chromium:738763, chromium:745844
Change-Id: I9f0e7f321e7f44ab5b36c06dd4c5633611370807
Reviewed-on: https://chromium-review.googlesource.com/581647
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46830}
This is so that we can distinguish hash tables by instance type. We can
then introduce maps for each kind of hash tables to further distinguish.
R=mstarzinger@chromium.org
Bug: v8:6593
Change-Id: I1a532884758e571abdfe2e2743fc5ea611d12f7e
Reviewed-on: https://chromium-review.googlesource.com/581009
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46828}
This reverts commit 6e27386d68.
Reason for revert: There will be another much simpler and
back-mergeable fix.
Original change's description:
> Reland "[runtime] Add shortcuts for elements kinds transitions."
>
> This is a reland of b90e83f5da
> Original change's description:
> > [runtime] Add shortcuts for elements kinds transitions.
> >
> > The shortcuts ensure that field type generalization is properly
> > propagated in the transition graph.
> >
> > Bug: chromium:738763
> > Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
> > Reviewed-on: https://chromium-review.googlesource.com/567992
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46622}
>
> Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
> Change-Id: I93974e3906b2c7710bd525f15037a2dd97f263ad
> Reviewed-on: https://chromium-review.googlesource.com/575227
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46759}
TBR=ulan@chromium.org,jkummerow@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
Change-Id: I203dc748c47db554e0a86d61f0e2b7b8b96f2370
Reviewed-on: https://chromium-review.googlesource.com/581547
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46826}
Simplify the model for generating Awaits, because the resume point is
always immediately following the suspend point, and registers used are
always the same for both operations.
Includes a minor refactoring of BytecodeGenerator::VisitYield() to
perform iterator result creation before the SuspendGenerator bytecode,
rather than between SuspendGenerator and Return. This adds a small
number of bytecodes for each yield.
BUG=v8:2355, v8:5855
Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089
Reviewed-on: https://chromium-review.googlesource.com/576286
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46820}
This reverts commit 69c8f16da7.
Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154
BUG=chromium:747154
Original change's description:
> [Turbofan] Merged the OSR phase into the graph building phase.
>
> Now the OSR phase is only used when OSRing from the ast graph builder.
> When OSRing from Turbofan, the implementation is now in the graph
> building phase, at the beginning of the VisitBytecode function.
> We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
> nor nodes for the possible code of the OSRed function which is before
> the OSRed loops.
>
> The trimming and reducing of the OSR phase is not done either. This
> change in the way the way the OSR is done enabled to remove the
> workaround to the bug mentioned below.
>
> Bug: v8:6112
> Bug: v8:6518
> Change-Id: I1c9231810b923486d55ea618d550d981d695d797
> Reviewed-on: https://chromium-review.googlesource.com/543042
> Commit-Queue: Alexandre Talon <alexandret@google.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46801}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com
Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6112, v8:6518
Reviewed-on: https://chromium-review.googlesource.com/581288
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46817}
Removes the SharedFunctionInfo field from the ParseInfo structure. Instead
require a SharedFunctionInfo to be explicitly passed to ParseFunction.
Also renames GetUnoptimizedCode to CompileUnoptimizedFunction to make it
clear it should only be called for non-top-level code.
BUG=v8:5203
Change-Id: Ibce016e6a5290c3685f7f0a2f5fb1eb2df2ffc3b
Reviewed-on: https://chromium-review.googlesource.com/574589
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46814}
This reverts commit 4851745fe3.
Reason for revert: Top crasher on Canary, see https://crbug.com/746935
Original change's description:
> [literals] Introduce CreateEmptyArrayLiteral Bytecode
>
> Empty Array literals are amongst the most commonly used literal types on our
> top25 page list. Using a custom bytecode we can drop the boilerplate for empty
> Array literals alltogether. However, we still need a proper AllocationSite to
> track ElementsKind transitions.
>
> Bug: v8:6211
> Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
> Reviewed-on: https://chromium-review.googlesource.com/567079
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46752}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com
Bug: v8:6211, chromium:746935
Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56
Reviewed-on: https://chromium-review.googlesource.com/580193
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46804}
Now the OSR phase is only used when OSRing from the ast graph builder.
When OSRing from Turbofan, the implementation is now in the graph
building phase, at the beginning of the VisitBytecode function.
We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
nor nodes for the possible code of the OSRed function which is before
the OSRed loops.
The trimming and reducing of the OSR phase is not done either. This
change in the way the way the OSR is done enabled to remove the
workaround to the bug mentioned below.
Bug: v8:6112
Bug: v8:6518
Change-Id: I1c9231810b923486d55ea618d550d981d695d797
Reviewed-on: https://chromium-review.googlesource.com/543042
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46801}
marking visitors.
This makes incremental and concurrent visitors of share function infos
side-effect free.
BUG=chromium:694255
Change-Id: I85ee7bac17f17bdbc101ef64ecfb46020b5b3458
Reviewed-on: https://chromium-review.googlesource.com/574851
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46796}
This patch implements a recent spec change [1] which increases the
bounds of precision for toFixed, toExponential and toPrecision.
The bounds are a compromise between SpiderMonkey and the other
engines.
[1] https://github.com/tc39/ecma262/pull/857
Bug: v8:6539
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I877aa35e08f3dcda63f5f9181fdecf3c227f2c35
Reviewed-on: https://chromium-review.googlesource.com/553378
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46793}
Apparently the name float.h causes problems on Windows when V8 is
compiled with Visual Studio, see the bug description.
R=clemensh@chromium.org
Bug: v8:6588
Change-Id: Iaa9c1e93e62509a779f1a8ddecbb03a53981cf8a
Reviewed-on: https://chromium-review.googlesource.com/578029
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46791}
Unscaled memory operations were missing disassembly output for vector registers,
so add support and rewrite as a macro.
Bug:
Change-Id: I6f388952dbe5a3b9f8a9b9c46e69ef63dc6655ba
Reviewed-on: https://chromium-review.googlesource.com/576177
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#46785}
Inlining heuristics in Turbofan used ast node count. Bytecode size
is a better approximation of the size of the graph than the
ast node count. This cl changes the heuristics to use the bytecode
size instead. Also removing the ast_node_count filed in the shared
function info. It was used only for the inlining heuristics.
Also removed the max_inlined_source_size flag which is no longer used.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8a2d2509c8e8d2779b33b817bb217de203d54ec3
Reviewed-on: https://chromium-review.googlesource.com/570055
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46771}
Async functions and generator declarations are only permitted as
StatementListItems, not as ExpressionStatements, and therefore not
as the entire body of an if statement, etc. Previously, they were
incorrectly permitted. However, ChakraCore and SpiderMonkey seem
to ban them in this context, and the feature was introduced relatively
recently, so it is likely to be web-compatible to ship the prohibition.
This patch also unifies the error message wording of async functions
and generators to ordinary functions, explaining more clearly what
the issue is.
Bug: v8:4483
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I31ed7818d6ab3e7e325031bfabb933dbf4512143
Reviewed-on: https://chromium-review.googlesource.com/568979
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46770}
There remained a few of regressions and we didn't see any significant
improvement in the real world with this turned on. This CL reverts all the
StringConcat bytecode work which landed.
BUG=v8:6243
Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8
Reviewed-on: https://chromium-review.googlesource.com/575130
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46769}
This patch changes the semi-space size to 512K.
> Original commit message:
> Revert "[heap] Allow a minimum semi-space size of 512K."
> This reverts commit 0d2ed6c328.
> The CL introduced perf regressions: crbug.com/735649.
> We are going to reland the CL in an isolated V8 roll to ensure
> that perf regressions are attributed correctly.
> Original commit message:
> > [heap] Allow a minimum semi-space size of 512K.
> > This CL also reduces the minimum semi-space size to 512K.
> > BUG=chromium:716032
> BUG=chromium:735649
Change-Id: Iabc377cba2911b28d51b98bb5b85134d4e893632
Reviewed-on: https://chromium-review.googlesource.com/575066
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46763}
This relands parts of "[heap] Allow a minimum semi-space size of 512K."
excluding the actual semi-space size change.
This partially reverts commit f341bb0f62
> Original commit message:
> Revert "[heap] Allow a minimum semi-space size of 512K."
> This reverts commit 0d2ed6c328.
> The CL introduced perf regressions: crbug.com/735649.
> We are going to reland the CL in an isolated V8 roll to ensure
> that perf regressions are attributed correctly.
> Original commit message:
> > [heap] Allow a minimum semi-space size of 512K.
> > This CL also reduces the minimum semi-space size to 512K.
> > BUG=chromium:716032
> BUG=chromium:735649
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5ed66b72104aa877d67fcd20bdadc807ea1551c3
Reviewed-on: https://chromium-review.googlesource.com/575065
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46762}
This is a reland of b90e83f5da
Original change's description:
> [runtime] Add shortcuts for elements kinds transitions.
>
> The shortcuts ensure that field type generalization is properly
> propagated in the transition graph.
>
> Bug: chromium:738763
> Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
> Reviewed-on: https://chromium-review.googlesource.com/567992
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46622}
Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
Change-Id: I93974e3906b2c7710bd525f15037a2dd97f263ad
Reviewed-on: https://chromium-review.googlesource.com/575227
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46759}
This adds handling for exceptional control projections when lowering
calls to {Array.prototype.map} in the call reducer.
R=mvstanton@chromium.org
TEST=mjsunit/optimized-map
BUG=v8:1956
Change-Id: If39ee836bbc3406a7fca4bad0d2c9321130cae2a
Reviewed-on: https://chromium-review.googlesource.com/575928
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46755}
This is a reland of a72b2f88a8
Original change's description:
> [arm] Restrict grouping pushes before a TailCall to registers only
>
> We optimize parallel moves performed before a TailCall by grouping adjacent
> pushes. This way, we may use a single instruction to push multiple registers at
> once. However, we also have support for pushing immediates and stack slots for
> which the benefit is questionnable therefore this patch removes support for
> them.
>
> Concerning immediate pushes, it looks like a mistake since we do not have
> support for this case in `AssembleMove` so this patch removes it. Furthermore,
> if we add a test for this case, we see that a `push ip` instruction is
> generated, effectively pushing whatever was in `ip` at the time instead of
> pushing a constant.
>
> Concerning stack slot pushes, we generate a more or less equivalent sequence of
> instructions.
>
> Finally, grouping floating point pushes is not used anywhere so this patch
> removes support for this also.
>
> Bug: v8:6553
> Change-Id: I9b820d33361fc442dd813f66e1f96cda41009110
> Reviewed-on: https://chromium-review.googlesource.com/567191
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
> Cr-Commit-Position: refs/heads/master@{#46718}
Bug: v8:6553
Change-Id: Ib9a55dae7cc5db6185d163c56088ff23426d04bb
Reviewed-on: https://chromium-review.googlesource.com/576087
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46754}
Empty Array literals are amongst the most commonly used literal types on our
top25 page list. Using a custom bytecode we can drop the boilerplate for empty
Array literals alltogether. However, we still need a proper AllocationSite to
track ElementsKind transitions.
Bug: v8:6211
Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
Reviewed-on: https://chromium-review.googlesource.com/567079
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46752}
Add SetProperties as the generic interface to set properties. In the
future, this will switch based on the input properties type and
correctly store the hash code.
This patch also updates tests to check against empty_property_array
instead of empty_fixed_array.
Bug: v8:6404
Change-Id: I39d324ea3ab3cc2c2223b6f4be64139bb88edd94
Reviewed-on: https://chromium-review.googlesource.com/574761
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46744}
The test for CanTreatHoleAsUndefined on keyed element access was
checking for stability of Object.prototype and Array.prototype and
even adding stability dependencies on both, which is too restrictive
and leads to unnecessary deoptimizations (and might disable further
optimization of the keyed access depending on the state of the
prototype objects during optimization). This was not intended and
is considered a (performance) bug.
Instead use the correct approach of checking whether the receiver's
prototype is one of the current Object.prototype or Array.prototype
objects (since the Array protector works isolate-wide), and then
check the Array protector and install an appropriate code dependency
on the protector only.
Bug: v8:6607
Change-Id: I0bcfe32813ca3693e7b22de31b03edb3509d0a27
Reviewed-on: https://chromium-review.googlesource.com/574849
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46743}
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them.
There are at least two changes which this CL produce:
- we don't provide break position when we load local variable (still provide when load variable from global),
- we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement.
More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing
Bug: v8:6425
Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda
Reviewed-on: https://chromium-review.googlesource.com/543161
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46742}
- use asm_tester instead of data variable name
- directly expose Variable and Label for convenience
Change-Id: I211fe07e236f96067037ca00c1435c1491121e6b
Reviewed-on: https://chromium-review.googlesource.com/574914
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46738}
This will allow us to concurrently allocate buckets during iteration.
Bug: chromium:738865
Change-Id: I88bd1ac152d1ef8b40395f0ba3e55a7c3e82f75d
Reviewed-on: https://chromium-review.googlesource.com/575990
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46737}
This allows to reuse the class e.g. in the baseline compiler.
R=titzer@chromium.org
Change-Id: I7251af16e8c74f267834a9cefb676edf3c9f3a07
Reviewed-on: https://chromium-review.googlesource.com/570020
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46735}
Signature maps should only be updated, but never copied. We had a bug
because we accidentally updated a copy of the map. This refactoring
prevents any such bugs in the future, and fixes more occurences where
we accidentally copied structs containing a signature map (the move-only
constraint also extends to all structs containing a signature map).
Drive-by: Make InstanceBuilder::NeedsWrappers const.
R=titzer@chromium.org
Bug: chromium:741750
Change-Id: Id919203d8c4078e608a1163e5c790c97d06a9753
Reviewed-on: https://chromium-review.googlesource.com/571791
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46728}
This reinstates the old behavior of Error.captureStackTrace prior to
4feafee9d9. Like the builtin Error constructors, captureStackTrace now formats
the stack trace lazily once it is accessed.
Bug: v8:5962
Change-Id: I03821b73d26b7b40809a1fea98f9c820bfa05d6b
Reviewed-on: https://chromium-review.googlesource.com/574530
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46727}
Previously,
➜ v8 (master) ✔ ./out.gn/x64.optdebug/d8
V8 version 6.1.0 (candidate)
d8> var x = undefined
undefined
d8> var [a] = x
(d8):1: TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
var [a] = x
^
TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
at (d8):1:11
Now,
➜ v8 (fix-iterator) ✔ ./out.gn/x64.optdebug/d8
V8 version 6.1.0 (candidate)
d8> var x = undefined
undefined
d8> var [a] = x
(d8):1: TypeError: x is not iterable
var [a] = x
^
TypeError: x is not iterable
at (d8):1:11
Bug: v8:6599, v8:6513
Change-Id: I71287a19166af0289e8f7708b8f41ad003ae87ae
Reviewed-on: https://chromium-review.googlesource.com/571175
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46723}
This reverts commit a72b2f88a8.
Reason for revert: Breaks https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/7093
Original change's description:
> [arm] Restrict grouping pushes before a TailCall to registers only
>
> We optimize parallel moves performed before a TailCall by grouping adjacent
> pushes. This way, we may use a single instruction to push multiple registers at
> once. However, we also have support for pushing immediates and stack slots for
> which the benefit is questionnable therefore this patch removes support for
> them.
>
> Concerning immediate pushes, it looks like a mistake since we do not have
> support for this case in `AssembleMove` so this patch removes it. Furthermore,
> if we add a test for this case, we see that a `push ip` instruction is
> generated, effectively pushing whatever was in `ip` at the time instead of
> pushing a constant.
>
> Concerning stack slot pushes, we generate a more or less equivalent sequence of
> instructions.
>
> Finally, grouping floating point pushes is not used anywhere so this patch
> removes support for this also.
>
> Bug: v8:6553
> Change-Id: I9b820d33361fc442dd813f66e1f96cda41009110
> Reviewed-on: https://chromium-review.googlesource.com/567191
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
> Cr-Commit-Position: refs/heads/master@{#46718}
TBR=danno@chromium.org,jarin@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org
Change-Id: Ib9db9e6e4f033aeea32741e04b1b884429acc800
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6553
Reviewed-on: https://chromium-review.googlesource.com/574908
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46719}
We optimize parallel moves performed before a TailCall by grouping adjacent
pushes. This way, we may use a single instruction to push multiple registers at
once. However, we also have support for pushing immediates and stack slots for
which the benefit is questionnable therefore this patch removes support for
them.
Concerning immediate pushes, it looks like a mistake since we do not have
support for this case in `AssembleMove` so this patch removes it. Furthermore,
if we add a test for this case, we see that a `push ip` instruction is
generated, effectively pushing whatever was in `ip` at the time instead of
pushing a constant.
Concerning stack slot pushes, we generate a more or less equivalent sequence of
instructions.
Finally, grouping floating point pushes is not used anywhere so this patch
removes support for this also.
Bug: v8:6553
Change-Id: I9b820d33361fc442dd813f66e1f96cda41009110
Reviewed-on: https://chromium-review.googlesource.com/567191
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46718}
This is the ia32 implementation of the CL
https://codereview.chromium.org/2763593002
Original message:
[wasm][arm] Add an additional stack check for functions with big frames.
Stack overflow checks are typically implemented as part of the TurboFan
graph of a function. This means that the stack check code is executed
after frame construction. When a frame is too big, though, there may not
be enough space on the stack anymore to throw the stack overflow
exception after frame construction. With this CL we do an additional
stack check before frame construction for functions with big frames.
As discussed offline with mstarzinger, I do this change currently only
for WebAssembly.
This CL contains only the changes for arm. I will do the other platforms
in separate CLs.
Bug:v8:6318
R=neis@chromium.org, titzer@chromium.org
Change-Id: Ibeedc5c4c4571cffd3a9c58016ddc44b64e2bf02
Reviewed-on: https://chromium-review.googlesource.com/568305
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46711}
If the incremental marker discovers more marking work and the concurrent
marking tasks have already exited, then new concurrent marking tasks
are scheduled to help the main thread marker.
BUG=chromium:694255
Change-Id: I559af62790e6034b23a412d3308ba8b6ae3d27c9
Reviewed-on: https://chromium-review.googlesource.com/574170
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46703}
This reverts commit a2fcdc7cc8.
Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
Original change's description:
> [runtime] Move profiler ticks from SFI to feedback vector
>
> Instead of counting profiler ticks on the shared function info (which is
> shared between native contexts), count them on the feedback vector
> (which is not). This allows us to continue pushing optimization
> decisions off the SFI, onto the feedback vector.
>
> Note that a side-effect of this is that ICs don't have to walk the stack
> to reset profiler ticks, as they can access the feedback vector directly
> from their feedback nexus.
>
> Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
> Reviewed-on: https://chromium-review.googlesource.com/544888
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46411}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
Reviewed-on: https://chromium-review.googlesource.com/574227
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46702}
Some of the benchmarks were pointing to the wrong test functions.
Bug:
Change-Id: I6f7850feec1da61bea7b8c1ac03c00d75400f458
Reviewed-on: https://chromium-review.googlesource.com/574023
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#46701}
There are wasm tests which are supposed to fail, but they fail for the
wrong reason (because blocks do not declare their type).
This CL fixes this, and changes the error output to contain the
expected and observed results for better debuggability.
R=titzer@chromium.org
Change-Id: Ibbd7883e43677a91f858575578586c9e9d1641d5
Reviewed-on: https://chromium-review.googlesource.com/571810
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46698}
This makes the runtime rely on the {HasBytecodeArray} predicate to
determine whether code generated by TurboFan was build without any
deoptimization support, as opposed to {asm_function}.
R=rmcilroy@chromium.org
BUG=v8:6589
Change-Id: Id124bed47a5fa02d31ff8fd3eee561b2df6c9226
Reviewed-on: https://chromium-review.googlesource.com/571786
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46694}
Goal of this CL: explicit return from non-async function has position after
return expression as return position (will unblock [1]).
BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
If one of these methods is called then next generated bytecode will get passed
position. It's general treatment for most cases.
Unfortunately it doesn't work for Returns:
- debugger requires source positions exactly on kReturn bytecode in stepping
implementation,
- BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
generates more then one bytecode and general solution will put return position
on first generated bytecode,
- it's not easy to split BuildReturn function into two parts to allow something
like following in BytecodeGenerator::VisitReturnStatement since generated
bytecodes are actually controlled by execution_control().
..->BuildReturnPrologue();
..->SetReturnPosition(stmt);
..->Return();
In this CL we pass ReturnStatement through ExecutionControl and use it for
position when we emit return bytecode right here.
So this CL only will improve return position for returns inside of non-async
functions, I'll address async functions later.
[1] https://chromium-review.googlesource.com/c/543161/
Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
Reviewed-on: https://chromium-review.googlesource.com/560738
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46687}
SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.
As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:
- Modification of MacroAssembler AssertGeneratorObject. No longer
accepts a SuspendFlags parameter to determine which type of check to
perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
AccessBuilders associated with the [[await_input_or_debug_pos]] field
in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
prevent the need for the other SuspendFlag values.
BUG=v8:5855
TBR=bmeurer@chromium.org
Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
Returning a double from ToFloat64 could lead to problems. If value_ has the bit
representation of a signaling NaN (sNaN), then returning it as double can cause
the signaling bit to flip, and value_ is returned as a quiet NaN (qNaN).
The usage of the Double wrapper also, makes the function ToFloat64AsInt
redundant, since the Double wrapper already has the AsUint64() method,
which returns an uint64_t.
R=ahaas@chromium.org
Change-Id: I1e627b97b2fb6110fc702fe58f2b83eb343e9ca2
Reviewed-on: https://chromium-review.googlesource.com/563215
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46680}
This is a reland of 5648aad553.
Previous compile error should be fixed by disabling strict aliasing
assumptions on gyp: https://chromium-review.googlesource.com/c/571806
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org
Bug: chromium:610330
Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
Reviewed-on: https://chromium-review.googlesource.com/570578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46679}
Bug: v8:6000
Change-Id: I8c068383300ba869a87f836504c84ea08fcff87e
Reviewed-on: https://chromium-review.googlesource.com/568307
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46675}
- Add more conformance tests for proxy call and calling undetectable
- This improves the performance of calling a proxy by ~5x
Bug: v8:6558, v8:6557
Change-Id: I5fe78d7ca703cfe86a2a14e39f0b6d88bb8c8e03
Reviewed-on: https://chromium-review.googlesource.com/570023
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#46673}
This reverts commit 20d5048a6f.
Revert "[heap] Ensure that concurrent marking tasks exit before heap tear down."
This reverts commit 387f65d41a.
Reason: concurrent marking tasks waiting for a signal from the main thread
is susceptible to deadlocks. We should instead re-schedule concurrent marking
threads once they exit.
BUG=chromium:694255
Change-Id: I20db2f26b42e960f4cc04506d9598c1187b8a003
Reviewed-on: https://chromium-review.googlesource.com/571800
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46671}
This includes several changes. From most to least interesting:
- No longer implement AwaitExpressions using a do-expression.
- Reduces frame-size of async generators by not allocating temporary
variables to hold results of Await epxressions.
- Streamline and reduce generated bytecodes for Await.
- Debugger no longer emits a debug::kCallBreakLocation breakpoint for
the JS-builtin call performed for Await, and instead only emits such
a breakpoint if the operand of Await is actually a call.
- Push fewer parameters to Await* builtins, using the receiver for the
first parameter (possible now that the CallRuntime invocation not
part of the AST).
- Adds a new Await AST node. No new members or anything, but it seemed
palatable to avoid having `if (is_await())` in a number of
VisitSuspend functions.
BUG=v8:5855, v8:5099, v8:4483
R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.orgTBR=bmeurer@chromium.org
Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
Reviewed-on: https://chromium-review.googlesource.com/558806
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46666}
The code was already there, but there was a bug in it: Because of the
missing reference, we were only updating a *copy* of the signature map,
hence the update had no effect.
This intentially is a minimal CL, in order to allow for easy
backmerging.
More mitigations and tests are coming in a separate CL.
R=titzer@chromium.org
Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c
Reviewed-on: https://chromium-review.googlesource.com/570278
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46664}
The "test-disasm-arm64/DISASM_debug" test would fail on hardware because we
expected a "hlt" instruction instead of "brk". The former is specific to running
inside the simulator.
Bug:
Change-Id: I7a5a3d4c1a93d03bbf4c934037c565d27379c2b5
Reviewed-on: https://chromium-review.googlesource.com/570442
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46663}
Bug: v8:6000
Change-Id: Ia50108ebbf838e210d95cb268858394e6a66c88d
Reviewed-on: https://chromium-review.googlesource.com/567990
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46658}
Currently every VirtualMemory allocation on 64-bit systems
uses a random 46-bit address hint for ASLR.
This leads to wired page leak on MacOS discovered by Erik Chen (see
crbug.com/700928 and https://chromium-review.googlesource.com/c/557958/):
"The Darwin kernel [as of macOS 10.12.5] does not clean up page directory
entries [PDE] created from mmap or mach_vm_allocate, even after
the region is destroyed. Using a virtual address space that is too large
causes a leak of about 1 wired [can never be paged out] page per call to
mmap(). The page is only reclaimed when the process is killed."
This patch changes VirtualMemory to accept the hint parameter explicitly.
On MacOS the hints are confined to 4GB contiguous region. Algorithm:
- On startup, set heap.mmap_region_base_ to a random address.
- For each mmap use heap.mmap_region_base_ + (random_offset % (4*GB)).
BUG=chromium:700928
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2ae6a024e02fbe63f940105d7920b57c19abacc6
Reviewed-on: https://chromium-review.googlesource.com/558876
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46656}
This CL inlines the following builtins into TurboFan
- %MapIteratorPrototype%.next
- %SetIteratorPrototype%.next
following the design that we are using for Array iteration already
(different instance types for the different kinds of iterators). Details
can be found in the relevant design document at:
https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8
The key to great performance here is to ensure that the inlined code
allows escape analysis and scalar replacement of aggregates to remove
the allocations for the iterator itself as well as the iterator results
and potential key/value arrays in the simple case of a for-of loop (and
by extension also in other constructs that reduce to for-of loops
internally), i.e.:
const s = new Set;
// ... do something with s
for (const x of s) {
// ...
}
Here the for-of loop shouldn't perform any allocations of helper
objects.
Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more
general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also
migrate the {Map,Set}.prototype.size getter inlining to the
JSBuiltinReducer, so that everything is in a single place.
R=jgruber@chromium.org
Bug: v8:6344, v8:6571, chromium:740122
Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d
Reviewed-on: https://chromium-review.googlesource.com/570159
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46655}
Only allow BindingIdentifier in BindingRestPattern and
ValidReferenceExpression in AssignmentRestPattern.
Also updated to a better, actionable error message.
Bug: v8:6500, v8:6513
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ifaba2f85c20bc20e263267e8c76d50a27075b87d
Reviewed-on: https://chromium-review.googlesource.com/550559
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46653}
