Inlines nameOrSourceURL and locationFromPosition of the Script object
at call sites.
R=jgruber@chromium.org
Bug: v8:7624
Change-Id: If217d4c1412fa22aaa856a017f73be4c803e70ac
Reviewed-on: https://chromium-review.googlesource.com/997741
Commit-Queue: Simon Zünd <szuend@google.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52427}
This reverts commit f9a2e24bbc.
Reason for revert: gc stress failures not all fixed by follow up.
Original change's description:
> [cleanup] Refactor the Factory
>
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
>
> This saves about 20KB of binary size on x64.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}
TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.
This saves about 20KB of binary size on x64.
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
This is a reland of 7a2c371383
Original change's description:
> [debug] introduced runtime side effect check
>
> This CL demonstrates minimum valuable addition to existing debug evaluate
> without side effects mechanism.
> With this CL user can evaluate expressions like:
> [a,b] // create any kind of temporary array literals
> [a,b].reduce((x,y) => x + y, 0); // use reduce method
> [1,2,3].fill(2); // change temporary arrays
>
> The core idea: any change of the object created during evaluation without
> side effects is side effect free. As soon as we try to store this temporary
> object to object existed before evaluation we will terminate execution.
>
> Implementation:
> - track all objects allocated during evaluation and mark them as temporary,
> - patch all bytecodes which change objects.
>
> A little more details (including performance analysis): [1].
>
> [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
>
> Bug: v8:7588
> Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
> Reviewed-on: https://chromium-review.googlesource.com/972615
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52370}
Bug: v8:7588
Change-Id: Ibc92bf19155f2ddaedae39b0c576b994e84afcf8
Reviewed-on: https://chromium-review.googlesource.com/996760
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52373}
This reverts commit 7a2c371383.
Reason for revert: msan is broken
Original change's description:
> [debug] introduced runtime side effect check
>
> This CL demonstrates minimum valuable addition to existing debug evaluate
> without side effects mechanism.
> With this CL user can evaluate expressions like:
> [a,b] // create any kind of temporary array literals
> [a,b].reduce((x,y) => x + y, 0); // use reduce method
> [1,2,3].fill(2); // change temporary arrays
>
> The core idea: any change of the object created during evaluation without
> side effects is side effect free. As soon as we try to store this temporary
> object to object existed before evaluation we will terminate execution.
>
> Implementation:
> - track all objects allocated during evaluation and mark them as temporary,
> - patch all bytecodes which change objects.
>
> A little more details (including performance analysis): [1].
>
> [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
>
> Bug: v8:7588
> Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
> Reviewed-on: https://chromium-review.googlesource.com/972615
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52370}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,leszeks@chromium.org
Change-Id: Ied1739c6308b13a4981189e0999f5912316cf456
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7588
Reviewed-on: https://chromium-review.googlesource.com/996135
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52371}
This CL demonstrates minimum valuable addition to existing debug evaluate
without side effects mechanism.
With this CL user can evaluate expressions like:
[a,b] // create any kind of temporary array literals
[a,b].reduce((x,y) => x + y, 0); // use reduce method
[1,2,3].fill(2); // change temporary arrays
The core idea: any change of the object created during evaluation without
side effects is side effect free. As soon as we try to store this temporary
object to object existed before evaluation we will terminate execution.
Implementation:
- track all objects allocated during evaluation and mark them as temporary,
- patch all bytecodes which change objects.
A little more details (including performance analysis): [1].
[1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
Bug: v8:7588
Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
Reviewed-on: https://chromium-review.googlesource.com/972615
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52370}
Before reporting coverage data, we attempt to reduce clutter by
merging nested and consecutive ranges. Nested ranges are merged, if
the child range has the same execution count as the parent range.
Sibling ranges are merged, if one sibling begins where the other ends
and execution counts are identical.
This allowed an invalid transformation in which a range with an
execution count of 1 would be merged into the parent change, but the
sibling range with identical start and end points and a count of 0
would remain, effectively deleting the covered range.
For example:
{start: 0, end: 10, count: 1},
{start: 5, end: 8, count: 1}, // It's invalid to remove this.
{start: 5, end: 8, count: 0}
The fix is to separate the parent and sibling merge passes, and
removing duplicate ranges in-between.
Bug: chromium:827530
Change-Id: Ic35eae1d4a106746570ce9cb412ed6710ef6da53
Reviewed-on: https://chromium-review.googlesource.com/992114
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52352}
Makes CallHandlerInfo its own instance type, with an additional
map to distinguish side-effect-free handlers. In a followup, we
can expose an API flag to set the map.
This CL does not support whitelisting calls to ObjectTemplates
that use SetCallAsFunctionHandler().
Bug: v8:7515
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ie32fe144046a9fae3e3b1ea5602b0da3db8a5616
Reviewed-on: https://chromium-review.googlesource.com/965741
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52328}
We need to bypass shortcuts when executing accessors defined via FunctionTemplate
if we have break points at function entry.
R=ishell@chromium.org, jgruber@chromium.org
Bug: v8:7596
Change-Id: I0e1bdbbba0f7dcd0fb7fe90d35b18234d073fe94
Reviewed-on: https://chromium-review.googlesource.com/980316
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52276}
The embedder can get notification when V8 heap size approaches the heap limit
and can extend the heap limit if needed using
- v8::Isolate::AddNearHeapLimitCallback
- v8::Isolate::RemoveNearHeapLimitCallback
This generalizes the exiting v8::debug::SetOutOfMemoryCallback API.
Bug: chromium:824214
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia444cb7efb6fe85c57fa3785e8fd1d8b654a5224
Reviewed-on: https://chromium-review.googlesource.com/979447
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52238}
We don't want to run into the situation of breaking inside of
debug-evaluate. That would get even more confusing with throw-on-side-effect.
R=kozyatinskiy@chromium.org
Bug: v8:7592
Change-Id: I93f5de63d8943792ff000dbf7c6311df655d3793
Reviewed-on: https://chromium-review.googlesource.com/978164
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52227}
This is a reland of d8f564eac6TBR=mstarzinger@chromium.org,yangguo@chromium.org,jgruber@chromium.org
Original change's description:
> Reland: Remove SFI code field
>
> Remove the SharedFunctionInfo code field, inferring the code object
> from the function_data field instead. In some cases, the function_data
> field can now hold a Code object (e.g. some WASM cases).
>
> (Reland of https://chromium-review.googlesource.com/952452)
>
> TBR=mstarzinger@chromium.org
>
> Bug: chromium:783853
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: I10ea5be7ceed1b51362a2fad9be7397624d69343
> Reviewed-on: https://chromium-review.googlesource.com/970649
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52136}
Bug: chromium:783853
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I5187851b923e9a92f43daf8cb99e662786cbb839
Reviewed-on: https://chromium-review.googlesource.com/975942
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52159}
Remove the SharedFunctionInfo code field, inferring the code object
from the function_data field instead. In some cases, the function_data
field can now hold a Code object (e.g. some WASM cases).
(Reland of https://chromium-review.googlesource.com/952452)
TBR=mstarzinger@chromium.org
Bug: chromium:783853
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I10ea5be7ceed1b51362a2fad9be7397624d69343
Reviewed-on: https://chromium-review.googlesource.com/970649
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52136}
Remove the SharedFunctionInfo code field, inferring the code object
from the function_data field instead. In some cases, the function_data
field can now hold a Code object (e.g. some WASM cases).
Bug: chromium:783853
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I1219a4d6aa5abaa9fee54dda883da7a3186e347a
Reviewed-on: https://chromium-review.googlesource.com/952452
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52064}
In order to remove the construct_stub field of the SFI we need all
construct stubs to be the same, and do any branching at runtime
instead. For builtins we don't need to set the construct stub because
the builtins construct stub will call into it for us.
There should only be two builtins left without the builtins construct
stub: Array and InternalArray, which are special cases that need to
be dealt with in another CL.
Bug: v8:7503
Change-Id: If0d419399a9ee22c09cf2a5a3d3dbea7a04dee77
Reviewed-on: https://chromium-review.googlesource.com/968862
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52046}
With this CL the name of an SFI is either stored directly on the SFI
itself (for uncompiled ones) or on the related ScopeInfo if present.
- Combine scope_info and name field on SFI into name_or_scope_info field
- Change the name of a couple of SFI accessors: name => Name,
has_shared_name => HasSharedName, set_name => SetName
- Add Runtime::kGetFunctionName due to more complex SFI name accessing
Bug: v8:7066
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Idcce158446c9447b92d9a15125d086952c6e0824
Reviewed-on: https://chromium-review.googlesource.com/964201
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52001}
This CL ads a StartPosition and EndPosition accessors on SFI and
ScopeInfo to facilitate future refactoring. In a future CL the
start and end position are no longer stored directly on SFIs.
This CL will temporarily increase memory since the position info
is duplicated on the SFI and the ScopeInfo.
Drive-by-fix: Clean up some constants in ScopeInfo
Bug: v8:7066
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I1a8c5dd4e2156c007e04d92e72e478b915516e0d
Reviewed-on: https://chromium-review.googlesource.com/955629
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51987}
Adds a flag onto InterceptorInfo to mark an interceptor's getter,
query, and enumerator callbacks as side-effect-free.
Bug: v8:7515
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iafc5d2fa554d6d9a38604e179ea5b884c3b77af0
Reviewed-on: https://chromium-review.googlesource.com/957870
Commit-Queue: Erik Luo <luoe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51969}
Annotate global handle with label to identify the context held alive for
debugging in DevTools
Bug: chromium:811842
Change-Id: I24f08b4d01939421ba1b7ec7b03982f00ebbdd1a
Reviewed-on: https://chromium-review.googlesource.com/962788
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51936}
- Add a new bytecode for the ToString operation, replacing the old
intrinsic call (currently does not collect type feedback).
- Add a new AST node to represent TemplateLiterals, and avoid
generating unnecessary ToString operations in some simple cases.
- Use a single feedback slot for each string addition, because the
type feedback should always be the same for each addition
This seems to produce a very slight improvement on JSTests benchmarks
and bench-ruben.js from v8:7415, and it's possible that type feedback
for the ToString bytecode could provide more opportunities to eliminate
the runtime call in TurboFan.
Doesn't touch tagged templates
[esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
Fixes an error where TemplateLiteral printing in --print-ast
would try to read an element beyond the length of a vector.
BUG=v8:7415, chromium:820596
R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
Reviewed-on: https://chromium-review.googlesource.com/958408
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51933}
This reverts commit 8ae19e08b1.
Reason for revert:
Speculative revert for layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/22215
See:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original change's description:
> [esnext] re-implement template strings
>
> - Add a new bytecode for the ToString operation, replacing the old
> intrinsic call (currently does not collect type feedback).
> - Add a new AST node to represent TemplateLiterals, and avoid
> generating unnecessary ToString operations in some simple cases.
> - Use a single feedback slot for each string addition, because the
> type feedback should always be the same for each addition
>
> This seems to produce a very slight improvement on JSTests benchmarks
> and bench-ruben.js from v8:7415, and it's possible that type feedback
> for the ToString bytecode could provide more opportunities to eliminate
> the runtime call in TurboFan.
>
> Doesn't touch tagged templates
>
> BUG=v8:7415
> R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
>
> Change-Id: If5a8c68558431f058db894d65776324abf54218e
> Reviewed-on: https://chromium-review.googlesource.com/945408
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Cr-Commit-Position: refs/heads/master@{#51853}
TBR=rmcilroy@chromium.org,caitp@igalia.com,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Id0529b065493ffc20c8f2b1abacc4c1484c3c046
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7415
Reviewed-on: https://chromium-review.googlesource.com/958163
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51862}
- Add a new bytecode for the ToString operation, replacing the old
intrinsic call (currently does not collect type feedback).
- Add a new AST node to represent TemplateLiterals, and avoid
generating unnecessary ToString operations in some simple cases.
- Use a single feedback slot for each string addition, because the
type feedback should always be the same for each addition
This seems to produce a very slight improvement on JSTests benchmarks
and bench-ruben.js from v8:7415, and it's possible that type feedback
for the ToString bytecode could provide more opportunities to eliminate
the runtime call in TurboFan.
Doesn't touch tagged templates
BUG=v8:7415
R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
Change-Id: If5a8c68558431f058db894d65776324abf54218e
Reviewed-on: https://chromium-review.googlesource.com/945408
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51853}
This patch removes the TypedArrayConstructor_ConstructStub builtin,
merging its functionality into the refactored TypedArrayConstructor
TurboFan builtin.
This brings us closer to our goal of deprecating the `construct_stub`
field in `SharedFunctionInfo`.
Bug: v8:7503, v8:7518
Change-Id: I264aa0933b3c80814e021b05033636196dc289da
Reviewed-on: https://chromium-review.googlesource.com/956044
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51843}
Previously we used a FixedArray for the FeedbackMetadata, packing bits
of information into Smi fields. On 64-bit platforms, we waste at least
half of the available memory by using the Smi representation.
Given that this is just raw data (no pointers), we can just use a new
type that uses the existing packing scheme to store the data in int32
format instead.
This CL changes FeedbackMetadata to a new subclass of HeapObject. This
is to reduce the API surface exposed, in comparison to extending/using
a more general purpose data structure like ByteArray, which is also just
raw data.
FeedbackMetadata only exposes general purpose methods for accessing
slots, but hides the implementation detail of packing bits into int32
fields.
This CL also introduces a sentinal EmptyFeedbackMetadata, because there
are ~750 empty FeedbackMetadata objects when running an empty program in
V8. These are probably for builtins.
Bug: v8:7500
Change-Id: Ic85563153abbd71a22854cee8519260c32b1e9ab
Reviewed-on: https://chromium-review.googlesource.com/945730
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51842}
The next CL will add an actual WeakFixedArray which contains in-place weak
references.
Also removes FLAG_trace_weak_arrays which is not super useful.
BUG=v8:7308
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I016880ecc66b03b406f7184b7f72ab514cb65428
Reviewed-on: https://chromium-review.googlesource.com/951730
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51789}
Instead of computing the disassmebly and offset tables eagerly on
registering a WASM function with a debugger agent, only generate
it when the source or offset tables are actually required. This is
implemented using a lazy, memoizing supplier that is shared
between the debugger agent and wasm translator.
Bug: chromium:794941
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1a2f7dd71ab65c80f91ddee4f7babbdf33d2e74b
Reviewed-on: https://chromium-review.googlesource.com/918641
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51762}
Instead of a hard-coded list of function addresses, we now use a flag
on the AccessorInfo object to annotate whether the getter can cause any
side effect.
Future changes will extend this to InterceptorInfo, CallHandlerInfo, and
expose this through the API.
R=jgruber@chromium.org, luoe@chromium.org
Bug: v8:7515
Change-Id: Id0fedf03493c3bd81913557a5681f8f63660f6a4
Reviewed-on: https://chromium-review.googlesource.com/945909
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51756}
This changes the encoding of the {HandlerTable} from an array of Smi
values to a byte array. It allows embedding of said array into the
instruction stream of {Code} objects (similar to how safepoint tables
work). For interpreted bytecode the table is attached as a {ByteArray}
to the bytecode.
The advantage of this approach is a more compact encoding and also the
ability to move such tables easily off the GC'ed heap if needed (as is
done for WebAssembly code for example).
R=jarin@chromium.org
Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d
Reviewed-on: https://chromium-review.googlesource.com/934642
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51589}
The list of runtime function use counts was generated with:
$ grep -o '^ *F(\w*' src/runtime/runtime.h | sed 's/^ *F(//' | sort | while read f; do USE_COUNT=$(git grep "\(Runtime::k\|Runtime::kInline\|%\|%_\)$f" | wc -l); echo $USE_COUNT $f; done
This reduces libv8.so size by 59K on an x64 release build.
Bug: v8:7310
Change-Id: Ib4d097e63ed065f41bf73e9529e4354575be5229
Reviewed-on: https://chromium-review.googlesource.com/934272
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51526}
Adding the StringSubstring simplified operator is a precursor to
improve inlining of String.p.{substr,substring,slice}.
This also contains a drive-by renaming to normalize different
spellings of 'Substring'.
Bug: v8:7250, v8:7340
Change-Id: I89e0fbafeab80f5d2f3ef348a5303d32c0abfe0a
Reviewed-on: https://chromium-review.googlesource.com/919084
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51522}
Originally reviewed at https://chromium-review.googlesource.com/929429
and landed as r51486 / d50c7731e8.
Update in reland: whitelisted new builtins as side effect free.
Bug: v8:6791
Change-Id: Iff45700c8a4eca23f3ee6fc9c0cb340dc027cbc6
Reviewed-on: https://chromium-review.googlesource.com/932802
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51491}
This is preparatory cleanup work for eventually tracking the functions
(rather than concrete closures) in the CALL_IC, also for builtins like
the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
adds a new FeedbackCell type, which is used by JSFunctions consistently
now to reference the feedback vector (or undefined if not the function
is not compiled yet or is a native/asm.js function).
This also changes the calling convention for FastNewClosure builtin and
the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
instead of the parent FeedbackVector and the slot index. In addition we
eliminate the now unused %InterpreterNewClosure runtime function.
Bug: v8:2206, v8:7253, v8:7310
Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
Reviewed-on: https://chromium-review.googlesource.com/928403
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51474}
Unifies GetSharedFunctionForStreamedScript with GetSharedFunctionForScript
so that both share a more similar API and some common code can be moved to
common helpers.
Introduces a Compiler::ScriptDetails struct to hold script meta-data
used to build new script objects.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3e6b4cd50da9bb92ef5a2bfd666a09b3619c34a4
Reviewed-on: https://chromium-review.googlesource.com/924189
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51438}
This CL removes a GC invocation which might not be needed anymore.
Change-Id: I27c57936677ba2ec0bc32588c485a2c3b6ffed01
Reviewed-on: https://chromium-review.googlesource.com/928241
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51428}
This ensures that breaking on inlined builtins works, even when
compiling concurrently. This CL also introduces the member
Isolate::AbortConcurrentOptimization.
R=sigurds@chromium.org
Bug: v8:178
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie6cbb48ebde18036888af2dd715862e7a14ddf9d
Reviewed-on: https://chromium-review.googlesource.com/912468
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51384}
This doesn't enable the warning yet, but adds V8_FALLTHROUGH annotations
in enough places so that v8 can build with the warning on on my linux box.
Found one real bug
(in effect-control-linearizer.cc,
https://chromium-review.googlesource.com/c/v8/v8/+/850392/3/src/compiler/effect-control-linearizer.cc#825
).
Bug: chromium:812686
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3542550b9c24b545641d0f0fc43f28f2780b0ab3
Reviewed-on: https://chromium-review.googlesource.com/911731
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51322}
instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
The description will be used to annotate roots in the heap snapshot.
Bug: chromium:811842
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic5c9a89d1921cabddb06783f08ba63740e72820d
Reviewed-on: https://chromium-review.googlesource.com/916564
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51286}
We reuse most of the infrastructure to set break points, with minor
differences when we encounter functions where we can only break on entry:
- PrepareFunctionForBreakPoints simply deopts all functions.
- Break point objects have the canonical source position 0.
- Break point is set/checked/cleared via bit on the DebugInfo.
- Debug::Break do not continue stepping since stepping is implemented via
regular break points and therefore do not interfere with break on entry.
I promise to add more tests.
Bug: v8:178
Change-Id: Ifc8231995c771286db0b848b811e1c3ad3b12494
Reviewed-on: https://chromium-review.googlesource.com/906245
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51152}
Cleanup CL that removes unnecessary builtins that were just wrapping
the throwing of errors. Use the ThrowTypeError and ThrowRangeError
helpers more consistently from CSA.
Change-Id: I2d0c3647340c88c457b27e16c0a81567869b7ec7
Reviewed-on: https://chromium-review.googlesource.com/906769
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51150}
Break points are cleared to empty fixed array, not undefined.
R=jgruber@chromium.org
Change-Id: Id8dcd08ed0aebc5c4f7745982cde48d562af9772
Reviewed-on: https://chromium-review.googlesource.com/904202
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51117}
Report an error during scope analysis if we're unable to find a
variable proxy for the given private field. This can happen if we try
to access a private field that was not defined or if we're outside
the class scope.
This doesn't correctly throw an early error when pre parsing a top
level function because we don't track it's variables.
Bug: v8:5368
Change-Id: I0a1193fe0ae213c0732fae5d435e150852a8d87d
Reviewed-on: https://chromium-review.googlesource.com/892093
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51082}
This check verifies that all .h files in the src/ directory have an
include guard of the form
#ifndef V8_PATH_TO_FILE_H_
#define V8_PATH_TO_FILE_H_
// ...
#endif // V8_PATH_TO_FILE_H_
The check can be skipped with a magic comment:
// PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d
Reviewed-on: https://chromium-review.googlesource.com/897487
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51079}
The FeedbackNexus classes initially were one-to-one with IC classes,
but over time this got out of date. We also found Nexus' useful, so
we made more classes even for cases that weren't ICs.
The inheritence and polymorphism became confusing and led to
duplication. Better, to just talk about a (single) FeedbackNexus.
Bug: v8:7344
Change-Id: I509dc9657895d56c3859de6e6589695cdff9e73e
Reviewed-on: https://chromium-review.googlesource.com/890452
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50997}
Some tests need to ensure all builtins are deserialized. This adds a
helper to make that easier.
Drive-by-refactoring: Centralize lazy-deserialization tracing.
TBR=rmcilroy@chromium.org
Bug: v8:6624
Change-Id: I1f7caa6c539b12aabcba5b7b28c50ad40355848b
Reviewed-on: https://chromium-review.googlesource.com/891822
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50959}
As part of the effort to despecialize WASM code, convert many uses of
WasmInstanceObject which were simply indirecting through to either
the compiled module or the shared module data with helpers on
the respective Frame objects.
R=mstarzinger@chromium.org
Bug:
Change-Id: I05bd1a18b1d81cceef8a80d9f6988e4f5d537e66
Reviewed-on: https://chromium-review.googlesource.com/876125
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50798}
Instead of requiring the pattern that a SuspendGenerator must be
followed by a Return, make SuspendGenerator return directly. This can,
in the future, simplify some of the reasoning around generator suspends.
Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5
Reviewed-on: https://chromium-review.googlesource.com/857463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50748}
This reverts commit 03e9d415c2.
Reason for revert: Correctness issues, see https://crbug.com/804159.
Bug: chromium:804159
Original change's description:
> Reland: Reimplement Object.entries/values as CSA to optimize performance.
>
> Add Object.entries/values builtins to debug-evaluate.cc whitelist macro.
> This fix revert commit of https://chromium-review.googlesource.com/c/v8/v8/+/859937
> Original is https://chromium-review.googlesource.com/c/v8/v8/+/810504
> >> Reimplements Object.entries/values as CSA to optimize performance. See more detail about https://bugs.chromium.org/p/v8/issues/ Issue 6804.
>
> This reverts commit 1b49f725ac.
>
> Bug: v8:6804
> Change-Id: I57e8b66e1c4ece2abb52e1630a97fbfd4070d810
> Reviewed-on: https://chromium-review.googlesource.com/860679
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50492}
TBR=yangguo@chromium.org,cbruni@chromium.org,jgruber@chromium.org,ishell@chromium.org,brn@b6n.ch
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6804
Change-Id: I39b1854ca7c2f57819ba377f84560356d3756bfb
Reviewed-on: https://chromium-review.googlesource.com/877886
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50746}
Until now, String.prototype.{trimLeft,trimRight} were non-standard
language extensions, required for Web compatibility.
The proposal at https://github.com/tc39/proposal-string-left-right-trim
standardizes this functionality as String.prototype.{trimStart,trimEnd},
and defines String.prototype.{trimLeft,trimRight} as aliases for
backwards compatibility.
This patch implements that proposal behind the --harmony-string-trimming
flag.
Bug: v8:6530
Change-Id: Id21e624c12a79e6b782efb049a48901b9da7db71
Reviewed-on: https://chromium-review.googlesource.com/867044
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50717}
This adds a new simplified operator NumberToString, which just lowers to
a call to the NumberToString builtin, and hooks that up to the typed
lowering (addressing a long-standing TODO).
Drive-by-fix: Also remove the %NumberToString runtime entry, and just
always use the %NumberToStringSkipCache entry from CSA, since we only
go there if the cache lookup already failed.
Bug: v8:5267, v8:7109
Change-Id: I5ca698c98679653813088a404f1fd38903a73c0e
Reviewed-on: https://chromium-review.googlesource.com/779099
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50636}
Instead of bailing out and assuming everything will be fine if a builtin
hasn't been deserialized yet, deserialize eagerly and perform the full
check.
Change-Id: I60b0d33786a266e124358e2eebe926d8f785881d
Reviewed-on: https://chromium-review.googlesource.com/859998
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50529}
This changes the names of the builtins on the Promise.prototype to match
the general naming convention and make it easier to tell what the
builtin is about just by looking at its name.
Bug: v8:7253
Change-Id: I906cc6fc14a6b9d8ffe9c0dcfd94b50439c4cfcf
Reviewed-on: https://chromium-review.googlesource.com/850698
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50367}
This patch breaks out bailout reasons into two enum classes.
This helps save 3 bits on the SharedFunctionInfo as we don't have to
track the abort reasons.
Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97
Reviewed-on: https://chromium-review.googlesource.com/848244
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50364}
This reverts commit 2a8e1e4a94.
Reason for revert: Time outs were caused by infra issues.
Original change's description:
> Revert "[debugger] do not try to find saved context before DebugEvaluate::Local"
>
> This reverts commit ea7499df6d.
>
> Reason for revert: Speculative, but this CL seems correlated with a bunch of timeouts on Linux:
>
> https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/19540
>
> Original change's description:
> > [debugger] do not try to find saved context before DebugEvaluate::Local
> >
> > Current implementation produces crashes since sometimes saved context
> > is empty. It looks like we do not need to restore saved context since
> > we do not set debug context as current, at least all tests are passed.
> >
> > R=yangguo@chromium.org
> >
> > Bug: chromium:797573,chromium:792838
> > Change-Id: I1271640f6a18cbaaecfa1e99ed9ac28e0dbbb1da
> > Reviewed-on: https://chromium-review.googlesource.com/844979
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#50327}
>
> TBR=yangguo@chromium.org,kozyatinskiy@chromium.org
>
> Change-Id: I543201698c96c9762c481c1f6012cc13cb712842
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:797573, chromium:792838
> Reviewed-on: https://chromium-review.googlesource.com/846205
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50331}
TBR=bbudge@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org
Change-Id: I44e916c796b935c372ce418a3fad44aa25d6f863
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:797573, chromium:792838
Reviewed-on: https://chromium-review.googlesource.com/848132
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50332}
This reverts commit ea7499df6d.
Reason for revert: Speculative, but this CL seems correlated with a bunch of timeouts on Linux:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/19540
Original change's description:
> [debugger] do not try to find saved context before DebugEvaluate::Local
>
> Current implementation produces crashes since sometimes saved context
> is empty. It looks like we do not need to restore saved context since
> we do not set debug context as current, at least all tests are passed.
>
> R=yangguo@chromium.org
>
> Bug: chromium:797573,chromium:792838
> Change-Id: I1271640f6a18cbaaecfa1e99ed9ac28e0dbbb1da
> Reviewed-on: https://chromium-review.googlesource.com/844979
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50327}
TBR=yangguo@chromium.org,kozyatinskiy@chromium.org
Change-Id: I543201698c96c9762c481c1f6012cc13cb712842
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:797573, chromium:792838
Reviewed-on: https://chromium-review.googlesource.com/846205
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50331}
Current implementation produces crashes since sometimes saved context
is empty. It looks like we do not need to restore saved context since
we do not set debug context as current, at least all tests are passed.
R=yangguo@chromium.org
Bug: chromium:797573,chromium:792838
Change-Id: I1271640f6a18cbaaecfa1e99ed9ac28e0dbbb1da
Reviewed-on: https://chromium-review.googlesource.com/844979
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50327}
We were passing a pointer to an object allocated as
{InterpretedFrameImpl} in an {std::unique_ptr<InterpretedFrame>}.
The default deleter then called {delete ptr;} on a ptr of type
{InterpretedFrame*}, even though that object was allocated as
{InterpretedFrameImpl}. This error might caught by validators.
Fix this by passing a custom deleter on the unique_ptr.
R=ahaas@chromium.org, ulan@chromium.org
Bug: v8:7231
Change-Id: Ia18114236384813c4878319209ae4535fda56c41
Reviewed-on: https://chromium-review.googlesource.com/834510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50226}
This changes the implementation of
v8::ScriptCompiler::CompileFunctionInContext
See design doc: https://goo.gl/ppkK6QR=adamk@chromium.org, marja@chromium.org, mstarzinger@chromium.org
Bug: v8:7172, chromium:70895
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iab0b6e879c1a3b33b623bfa2af9c706643c06fa7
Reviewed-on: https://chromium-review.googlesource.com/810946
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50148}
This separates common logic that applies to both coverage/type profiling
(i.e. collecting feedback vectors into the list) from work that's only
required by coverage (resetting SFI::has_reported_binary_coverage and
FeedbackVector::invocation_count).
Bug: v8:6000
Change-Id: Icb36a8a6af34b3a425814d69653e331ca8f76cd5
Reviewed-on: https://chromium-review.googlesource.com/813922
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49956}
- Removes JS implementation and InnerArrayFind/InnerArrayFindIndex
- Adds TFJ, with TFS for slow continuation path
Some quick benchmarks show ~2x improvement for unoptimized code
and up to 16% improvement against optimized code (diminishes with
larger arrays as iterating dominates).
https://github.com/peterwmwong/v8-perf/blob/master/array-find-findIndex/README.md
Bug: chromium:791045, v8:1956, v8:5049, v8:7165
Change-Id: Ie16252ed495bbd91fe548b16d5ef6764de791a50
Reviewed-on: https://chromium-review.googlesource.com/804704
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49851}
This fixes debug-evaluate in the presence of a de-materialized function
object. The creation of an arguments object is now requested based on a
given frame (potentially inlined) instead of a target function. It makes
sure that multiple calls to {StandardFrame::Summarize} don't cause any
confusion when they give back non-identical function objects.
R=jgruber@chromium.org
TEST=debugger/debug/debug-evaluate-arguments
BUG=chromium:788647
Change-Id: I575bb6cb20b4657dc09019e631b5d6e36c1b5189
Reviewed-on: https://chromium-review.googlesource.com/796474
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49721}
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.
This CL
- removes the parser's special treatment of ** and **=, treating them
like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
Exponentiate builtin. For simplicity, they currently always collect
kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
the existing NumberPow and a generic-lowering to the Exponentiate
builtin. There is currently no speculative lowering.
Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.
Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).
This CL includes following addition to our protocol and v8-inspector.h:
- added Runtime.StackTraceId, this id represents stack trace captured
on debugger with given id,
- protocol client can fetch Runtime.StackTrace by
Runtime.StacKTraceId using Debugger.getStackTrace method,
- externalParent field is added to Debugger.paused event, it may
contain external parent stack trace,
- V8Inspector::storeCurrentStackTrace captures current stack trace
and returns V8StackTraceId for embedder this id can be used as
argument for V8Inspector::externalAsyncTaskStarted and
V8Inspector::externalAsyncTaskFinished method. Any async stack
trace captured between these calls will get passed external stack
trace as external parent. These methods are designed to be called
on different debuggers. If async task is scheduled and started on
one debugger user should continue to use asyncTask* API,
- Debugger.enable methods returns unique debuggerId.
TBR=dgozman@chromium.org,jgruber@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4
Reviewed-on: https://chromium-review.googlesource.com/786274
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49591}
This reverts commit 3a41b697cd.
Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250
Original change's description:
> [inspector] introduced stackTraceId and externalAsyncTask API
>
> Sometimes we need to capture stack trace on one debugger and use it
> later as a parent stack on another debugger (e.g. worker.postMessage).
>
> This CL includes following addition to our protocol and v8-inspector.h:
> - added Runtime.StackTraceId, this id represents stack trace captured
> on debugger with given id,
> - protocol client can fetch Runtime.StackTrace by
> Runtime.StacKTraceId using Debugger.getStackTrace method,
> - externalParent field is added to Debugger.paused event, it may
> contain external parent stack trace,
> - V8Inspector::storeCurrentStackTrace captures current stack trace
> and returns V8StackTraceId for embedder this id can be used as
> argument for V8Inspector::externalAsyncTaskStarted and
> V8Inspector::externalAsyncTaskFinished method. Any async stack
> trace captured between these calls will get passed external stack
> trace as external parent. These methods are designed to be called
> on different debuggers. If async task is scheduled and started on
> one debugger user should continue to use asyncTask* API,
> - Debugger.enable methods returns unique debuggerId.
>
> Bug: chromium:778796
> Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
> Reviewed-on: https://chromium-review.googlesource.com/754183
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49582}
TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:778796
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/786152
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49584}
Sometimes we need to capture stack trace on one debugger and use it
later as a parent stack on another debugger (e.g. worker.postMessage).
This CL includes following addition to our protocol and v8-inspector.h:
- added Runtime.StackTraceId, this id represents stack trace captured
on debugger with given id,
- protocol client can fetch Runtime.StackTrace by
Runtime.StacKTraceId using Debugger.getStackTrace method,
- externalParent field is added to Debugger.paused event, it may
contain external parent stack trace,
- V8Inspector::storeCurrentStackTrace captures current stack trace
and returns V8StackTraceId for embedder this id can be used as
argument for V8Inspector::externalAsyncTaskStarted and
V8Inspector::externalAsyncTaskFinished method. Any async stack
trace captured between these calls will get passed external stack
trace as external parent. These methods are designed to be called
on different debuggers. If async task is scheduled and started on
one debugger user should continue to use asyncTask* API,
- Debugger.enable methods returns unique debuggerId.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
Reviewed-on: https://chromium-review.googlesource.com/754183
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49582}
Old instrumentation was designed to collect promise creation stack and
promise scheduled stack together. In DevTools for last 6 months we
show only creation stack for promises. We got strong support from users
for new model. Now we can drop support for scheduled stacks and
simplify implementation.
New promise instrumentation is straightforward:
- we send kDebugPromiseThen when promise is created by .then call,
- we send kDebugPromiseCatch when promise is created by .catch call,
- we send kDebugWillHandle before chained callback and kDebugDidHandle
after chained callback,
- and we send separate kDebugAsyncFunctionPromiseCreated for internal
promise inside async await function.
Advantages:
- we reduce amount of captured stacks (we do not capture stack for
promise that constructed not by .then or .catch),
- we can consider async task related to .then and .catch as one shot
since chained callback is executed once,
- on V8 side we can implement required instrumentation using only
promise hooks,
Disadvantage:
- see await-promise test, sometimes scheduled stack was useful since we
add catch handler in native code,
Implementation details:
- on kInit promise hook we need to figure out why promise was created.
We analyze builtin functions until first user defined function on
current stack. If there is kAsyncFunctionPromiseCreate function then
we send kDebugAsyncFunctionPromiseCreated event. If there is
kPromiseThen or kPromiseCatch then only if this function is bottom
builtin function we send corresponded event to inspector. We need it
because Promise.all internally calls .then and in this case we have
Promise.all and Promise.then on stack at the same time and we do not
need to report this internally created promise to inspector.
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47
Reviewed-on: https://chromium-review.googlesource.com/765208
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49553}
Currently the SourcePositionTableBuilder requires a Zone because it
holds a ZoneVector<byte> of the encoded entries. Since ZoneVector is a
suboptimal data structure anyway, and for Liftoff we don't even have a
Zone allocated currently, this CL replaces the ZoneVector by
std::vector.
R=mstarzinger@chromium.org
Bug: v8:6600
Change-Id: I8010143e917e2351664e2b53746753b597f4407a
Reviewed-on: https://chromium-review.googlesource.com/779181
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49534}
This removes support for optimized frame which lack deoptimization
information. All optimized JavaScript frames now imply that the
underlying bytecode is available too.
R=rmcilroy@chromium.org
BUG=v8:6409
Change-Id: Ie73c0a376002466884388f1da9e1ec2741884596
Reviewed-on: https://chromium-review.googlesource.com/612162
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49442}
The backing store fixed array for collections needs to be allocated
in LOS if it exceeds the maximum regular heap object size.
Drive-by-fix: Only store fixed array map once as per TODO.
Bug: chromium:784862
Change-Id: I6b4dd2e45153ae107171e21bc7448e0d9b54b0ed
Reviewed-on: https://chromium-review.googlesource.com/771150
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49378}
This CL fixes uses of HandleSlackTracking which previously would write
fields twice. Additional checks ensure that only proper initial maps are
used with slack tracking.
Change-Id: Ifb03297635ed6b873eb8b27fec9794c9d36b71b6
Reviewed-on: https://chromium-review.googlesource.com/664810
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49331}
MIPS team has recently migrated to @mips.com e-mail address.
Dusan Simicic is no longer part of MIPS V8 team, therefore
his name is removed from OWNERS.
TBR=mstarzinger@chromium.org
NOTRY=true
Bug:
Change-Id: I67fde24a5b9214fa3fca05c0399888b8d18fc699
Reviewed-on: https://chromium-review.googlesource.com/758639
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49299}
This is in preparation for wasm on the native heap. All the
aforementioned API needs is the address where the JIT-ed code starts.
This refactoring reduces the dependency of the API to just that.
Bug: v8:6876
Change-Id: I00bbb171398f581db41b8a74ab719e8ea4db52c4
Reviewed-on: https://chromium-review.googlesource.com/755624
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49204}
In current implementation Object.getOwnPropertyDescriptor calls native
getter. It can produce side effects. We can avoid calling it.
DevTools frontend will show clickable dots and on click returns value.
This CL does not affect Blink and only affect several Node.js
properties, e.g. process.title.
R=yangguo@chromium.org
Bug: v8:6945
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5764c779ceed4d50832edf68b2b4c6ee2c2dd65c
Reviewed-on: https://chromium-review.googlesource.com/754223
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49152}
It is preparation step for step-into-worker. There are few changes:
- added breakOnAsyncCall flag for Debugger.stepInto. When flag is set
and async task is scheduled before step-into finished, we pause
execution with additional Debugger.paused event. This event contains
additional scheduledAsyncTaskId field.
- added Debugger.pauseOnAsyncTask. This method will pause execution as
soon as given async task is started.
This mechanism is replacement for Debugger.scheduleStepIntoAsync which
can not be used between multiple targets.
As result we can split async task scheduling in one target and
requesting break for this async task running in another target.
R=pfeldman@chromium.org
Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I77be0c880d91253d333c54a23a4c084e7b8549e9
Reviewed-on: https://chromium-review.googlesource.com/750071
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49127}
DebugBreak bytecode fetches current return value from debugger prior
dispatching original handler. So we can change its value on break.
R=leszeks@chromium.org,rmcilroy@chromium.org
Bug: chromium:656150
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I82d0bc82ff49923a748c0084d252d0fd214a2db8
Reviewed-on: https://chromium-review.googlesource.com/731679
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49122}
We have a check on maximum number of levels that can be inlined. This
in some cases causes performance cliffs, when we cannot inline a small
function because it has exceeded the number of levels. This cl removes
that check. The intuition is that, having gone down several levels in
a particular line stopping inlining that chain and exploring a new
call site may not be beneficial. This cl also introduces a absolute
limit on the number of nodes that can be inlined (including the small
functions).
Bug: v8:6871, chromium:779509
Change-Id: Id29639ff2fd85b84d8746da3fb78a82d4e9852e8
Reviewed-on: https://chromium-review.googlesource.com/743727
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49050}
This reverts commit ecd3a2ea3e.
Reason for revert: Bug 779509, a crash with chrome.
Original change's description:
> [TurboFan] Remove maximum inlining levels check from inlining heuristics
>
> We have a check on maximum number of levels that can be inlined. This
> in some cases causes performance cliffs, when we cannot inline a small
> function because it has exceeded the number of levels. This cl removes
> that check. The intuition is that, having gone down several levels in
> a particular line stopping inlining that chain and exploring a new
> call site may not be beneficial.
>
> Bug: v8:6871
> Change-Id: I120056db38e78ce48dff010b6cf994259238582a
> Reviewed-on: https://chromium-review.googlesource.com/741705
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49009}
TBR=mythria@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6871
Change-Id: I4766f911cb326c224af110be5c0dd7a44362a880
Reviewed-on: https://chromium-review.googlesource.com/743785
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49037}
We have a check on maximum number of levels that can be inlined. This
in some cases causes performance cliffs, when we cannot inline a small
function because it has exceeded the number of levels. This cl removes
that check. The intuition is that, having gone down several levels in
a particular line stopping inlining that chain and exploring a new
call site may not be beneficial.
Bug: v8:6871
Change-Id: I120056db38e78ce48dff010b6cf994259238582a
Reviewed-on: https://chromium-review.googlesource.com/741705
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49009}
Previously, V8's slice was implemented in a combination of C++ and a
Javascript fallback. The disadvantage of this approach was that the
fast-path required a call through the CEntryStub, which introduced
considerable overhead for small arrays with fast elements kinds.
Now the implementation primarily uses the CSA to generate both the
full spec-complaint implementation as well as fast paths for argument
objects and arrays with fast elements kinds. The CSA implementation
uses a C++ implementation fallback in select situations where the the
complexity of a CSA implementation would be too great and the
CEntryStub overhead is not decisive (e.g. slices of dictionary
elements arrays).
Performance results on semi-random arrays with small number of
elements (old vs. new):
smi copy: 48.7 ms vs. 12 ms
smi slice: 43.5 ms 14.8 ms
object copy: 35.5 ms 7.7 ms
object slice: 38.7 ms 8.8 ms
dictionary slice: 2398.3 ms vs. 5.4 ms
fast sloppy arguments slice: 9.6 ms vs. 7.2 ms
slow sloppy arguments slice: 28.9 ms vs. 8.5 ms
As a bonus, the new implementation is fully spec-compliant and fixes
at least one existing bug.
The design document for Array.prototype builtin rework can be found
at https://goo.gl/wFHe2n
Bug: v8:1956,v8:6601,v8:6710,v8:6978
Change-Id: Ia0155bedcf39b4577605ff754f416c2af938efb7
Reviewed-on: https://chromium-review.googlesource.com/574710
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48853}
Currently we incorrectly show global object as arrow function receiver.
With this CL:
- if this is used inside of function we show correct this value,
- if this is unused and V8 optimizes it out - we show undefined.
Second is known issue which we should address separately.
R=dgozman@chromium.org,yangguo@chromium.org
Bug: chromium:552753
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iac88a07fe622eb9b2f8af7ecbc4a32a56c8cdfaa
Reviewed-on: https://chromium-review.googlesource.com/723840
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48839}
The information that such functions must be parsed in module mode
didn't get properly propagated.
Also refactor some related code to make it more robust. In particular,
set parsing_module_ at parser construction time only.
Bug: v8:1569, v8:6919
Change-Id: Id136fb15c240373cad07c82025b778d0c0c43148
Reviewed-on: https://chromium-review.googlesource.com/716478
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48811}
This allocates and populates potential source position table before the
underlying {Code} objects is allocated. It essentially makes the field
holding said table immutable after allocation.
R=verwaest@chromium.org
BUG=v8:6792
Change-Id: If35462688a1b502f28ae84f73b82b5df5005735f
Reviewed-on: https://chromium-review.googlesource.com/727895
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48781}
Instead of re-iterating over the heap all the time, use the
list of feedback vectors on the isolate. This also avoids GC of vectors.
Bug: v8:5935
Change-Id: I0bb96fcf2b0feb9856e9806f812188de1fc7b37e
Reviewed-on: https://chromium-review.googlesource.com/668396
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48643}
Remove unused macros, and move macro definitions used only in a single
file into the file itself.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: If62107816ad1e6addf58705a075d3eba4f23bf08
Reviewed-on: https://chromium-review.googlesource.com/721381
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48625}
This is a reland of 61292f0b60
Original change's description:
> [inspector] breakpoint after last break position should not jump to first line
>
> R=jgruber@chromium.org
>
> Bug: chromium:730177
> Change-Id: I0f3666a333604cb80bb51410c5edf2aceb0c6ef5
> Reviewed-on: https://chromium-review.googlesource.com/717717
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48556}
TBR=jgruber@chromium.org
Bug: chromium:730177
Change-Id: I564cc5d7778f9d79780eae9dbe2d9aafaad4f466
Reviewed-on: https://chromium-review.googlesource.com/721468
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48615}
- Extract core StringPrototypeRepeat code into a TFS builtin (StringRepeat)
- Assumes arguments are a string and smi (no range checks)
- Add StringPrototypePadStart and StringPrototypePadEnd TFJ builtins
- Added StringPadAssembler to ensure common behavior
- Removed functionality from string.js
A quick benchmark shows significant performance gains for unoptimized
code (2.1x to 2.46x) and optimized code (1.03x - 1.56x).
https: //github.com/peterwmwong/v8-perf/blob/master/string-pad/README.md
Bug: v8:5049
Change-Id: I6e4fe99fb62a3edb3d6906fd4f78b3576b5b0d13
Reviewed-on: https://chromium-review.googlesource.com/720067
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48595}
New OWNERS jbarboza and mmallick and remove bjaideep.
Bug:
Change-Id: I3d7b8d13cad441bd60b1d598e5553716799ef739
Reviewed-on: https://chromium-review.googlesource.com/714136
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#48559}
New code should use nullptr instead of NULL.
This patch updates existing use of NULL to nullptr where applicable,
making the code base more consistent.
BUG=v8:6928,v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c
Reviewed-on: https://chromium-review.googlesource.com/718338
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48557}
In Debug mode, V8 disallows executing JavaScript during
`ScriptCompiler::CompileUnbound()` calls. This restriction
makes sense during compilation, but not really for the post-compile
notification, and currently at least one Node.js test
(`test/inspector/test-contexts.js`) fails because of this in debug mode.
Bug:
Change-Id: I930b5f06083c0e87f1613414da3dfe2bcdf0f386
Reviewed-on: https://chromium-review.googlesource.com/706943
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48421}
We use the naming convention <Constructor>Prototype<Method> for builtins
that implement methods on a certain builtin constructors prototype. Fix
the collection builtins (Map and Set) to match this naming convention.
Bug: v8:5049
Change-Id: I8ced50c2ac9ebc8f4390bcbbc6aec426a0026813
Reviewed-on: https://chromium-review.googlesource.com/707318
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48403}
Change the default to false. Block coverage will need to be
enabled explicitly via inspector protocol, which is already
being done.
R=franzih@chromium.org
Bug: v8:6738
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I08684ce7b501981bc376a6bc6181fabac9628a63
Reviewed-on: https://chromium-review.googlesource.com/689234
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48235}
And some refactoring to the existing code for LiveEdit.
R=jarin@chromium.org
Change-Id: Ic1d626db9722b39cbcd83bf6878fc24d6094e612
Reviewed-on: https://chromium-review.googlesource.com/687014
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48233}
Note that this also makes it possible to move several classes
into the module-compiler.cc file and inline their implementations.
This also allows removing several uses of wasm-module.h from
other places in V8 that include wasm-objects.h.
R=yangguo@chromium.org,clemensh@chromium.org,ahaas@chromium.org
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I303ee2bb49dc53c951d377a1b65699c1e0e91da7
Reviewed-on: https://chromium-review.googlesource.com/687494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48204}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=yangguo@chromium.org
Bug: v8:6837
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112
Reviewed-on: https://chromium-review.googlesource.com/681374
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48138}
I noticed that ScopeIterator::CurrentContext returns an empty Handle
whereas functions like ScopeIterator::CurrentScopeInfo call
Handle<Context>::null() instead. This commit suggests changing this for
consistency.
Bug:
Change-Id: I8735d655a8c0affeb6a18e74efe0d33bf6d5e899
Reviewed-on: https://chromium-review.googlesource.com/668440
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48057}
It's quite possible for DebugInfos to exist without the presence of a
bytecode array, since DebugInfos are created for all functions for which
we have a CoverageInfo. Free such objects properly.
Also move the corresponding deletion of CoverageInfos on unload up
before the early exit.
Bug: v8:6000
Change-Id: Idde45b222290aa8b6828b61ff2251918b8ed2aed
Reviewed-on: https://chromium-review.googlesource.com/664811
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48024}
If TypeProfile goes out of scope, ScriptData and Entry still rely on
TypeProfiles's type_profile_. Make type_profile_ a shared_ptr owned by all
three classes to prevent use after free.
Bug: v8:5933
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ida7d66dadc17a816cf4439a25e6f714edccffa2c
Reviewed-on: https://chromium-review.googlesource.com/659937
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48013}
Some API functions have no context and debug::ScopeIterator::
CreateForFunction is crashing on attempt to get context.
R=jgruber@chromium.org
Bug: chromium:759913
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0a9861ea2d19bceff97c4394b34a8dda45222b78
Reviewed-on: https://chromium-review.googlesource.com/661789
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47981}
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.
Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
Since we don't have a full-codegen compiler anymore, we no longer
generate Code::FUNCTION kind. Nice! Here is some cleanup.
Bug: v8:6409
Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762
Reviewed-on: https://chromium-review.googlesource.com/657817
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47951}
If Coverage goes out of scope, ScriptData, FunctionData, or BlockData still rely on
Coverage's coverage_. Make coverage_ a shared_ptr owned by all four classes.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifab5d05184cc5db0fd0a935254b967286295e63f
Reviewed-on: https://chromium-review.googlesource.com/657381
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47938}
The previous %StringCharCodeAt runtime entry (and the inlined intrinsic)
are obsolete and not used anymore (except in dedicated tests for this
runtime function), so remove it. And rename the %StringCharCodeAtRT
function, which is actually used to %StringCharCodeAt instead to have
a consistent naming scheme for runtime fallbacks.
Bug: v8:5049
Change-Id: I619429ef54f6efea61fc51ab9ed1d5cfe4417f99
Reviewed-on: https://chromium-review.googlesource.com/657719
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47928}
JavaScript is a dynamically typed language. But most code is
written with fixed types in mind. When debugging JavaScript,
it is helpful to know the types of variables and parameters
at runtime. It is often hard to infer types for complex code.
Type profiling provides this information at runtime.
Node.js uses the inspector protocol. This CL allows Node.js users
to access and analyse type profile for via Node modules or the
in-procress api. Type Profile helps developers to analyze
their code for correctness and performance.
Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
Add `takeTypeProfile` to the inspector protocol. It returns a list
of TypeProfileForScripts, which in turn contains the type profile for
each function. We can use TypeProfile data to annotate JavaScript code.
Sample script with data from TypeProfile:
function f(/*Object, number, undefined*/a,
/*Array, number, null*/b,
/*boolean, Object, symbol*/c) {
return 'bye';
/*string*/};
f({}, [], true);
f(3, 2.3, {a: 42});
f(undefined, null, Symbol('hello'));/*string*/
Bug: v8:5933
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d
Reviewed-on: https://chromium-review.googlesource.com/508588
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47920}
This speeds up the baseline performance of Object by 20%.
With this change, the callViaObject when run with --noopt
goes from 10718ms to 8577ms on the benchmark from:
http://benediktmeurer.de/2017/08/31/object-constructor-calls-in-webpack-bundles
Bug: v8:6772
Change-Id: Id0e54ba44204a1700885185ec360e1c56834fb73
Reviewed-on: https://chromium-review.googlesource.com/654900
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47888}
This is a reland of 9b35364c51
Original change's description:
> [cleanup] Replace more instances of List with std::vector.
>
> Bug: v8:6333
> Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
> Reviewed-on: https://chromium-review.googlesource.com/651413
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47854}
Bug: v8:6333
Change-Id: I5d9482b061f26b57550a421ea4099372dc80767f
Reviewed-on: https://chromium-review.googlesource.com/654898
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47884}
With lazy deserialization, the target code object may have been replaced
by DeserializeLazy. In that case, we can get the target builtin id from
the shared function info, and we need to skip RelocInfo iteration (it
doesn't exist yet).
Bug: v8:6624
Change-Id: I765b74de313e65bfdf0122f13535029994fc0de1
Reviewed-on: https://chromium-review.googlesource.com/655159
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47878}
Bug: v8:6333
Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
Reviewed-on: https://chromium-review.googlesource.com/651413
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47854}
This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
TBR: mstarzinger@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/647596
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47808}
This reverts commit 84c2dfce43.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
Original change's description:
> Remove weak-list of optimized JS functions.
>
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
>
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
>
> We needed to change/remove the cctests that used to check
> something on this list.
>
> Working in x64, ia32, arm64, arm, mips64 and mips.
>
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}
TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}
This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like
for (var k in o) {
var v = o[k];
// ...
}
and code like
for (var k in o) {
if (Object.prototype.hasOwnProperty.call(o, k)) {
var v = o[k];
// ...
}
}
which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.
For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:
forIn: 1516 ms.
forInHasOwnProperty: 1674 ms.
forInHasOwnPropertySafe: 1595 ms.
forInSum: 2051 ms.
forInSumSafe: 2215 ms.
Compared to numbers from V8 5.8 which is the last version running with
Crankshaft
forIn: 1641 ms.
forInHasOwnProperty: 1719 ms.
forInHasOwnPropertySafe: 1802 ms.
forInSum: 2226 ms.
forInSumSafe: 2409 ms.
and V8 6.0 which is the current stable version with TurboFan:
forIn: 1713 ms.
forInHasOwnProperty: 5417 ms.
forInHasOwnPropertySafe: 5324 ms.
forInSum: 7556 ms.
forInSumSafe: 11067 ms.
It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.
For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.
This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.
Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
This adds support for lowering {JSCreateArguments} within outermost
frames of type {CreateArgumentsType::kMappedArguments}. It will hence
enable escape analysis to work with such objects and allow for further
optimization.
This also adds a new {NewMappedArgumentsElements} simplfied operator.
Note that escape analysis support for this new operator will be done as
a follow-up.
R=tebbi@chromium.org
Change-Id: I0e2fac25c654f796433f57b116964053b6b68635
Reviewed-on: https://chromium-review.googlesource.com/641454
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47761}
heap-inl.h exposes the whole world, which is fine from other inline
files but not from regular headers.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I09ec67c6558682cb0d5181031bc39341a3f4c5bf
Reviewed-on: https://chromium-review.googlesource.com/643294
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47729}
This reverts commit f6d735095f.
Reason for revert: Perf regressions https://crbug.com/758126
Original change's description:
> [csa] Refactor large-object handling in string allocation
>
> CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to
> allocate very large strings. This CL refactors both methods to use
> AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need
> to specify explicitly if large-object allocation is possible or not.
>
> Bug: chromium:636391
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f
> Reviewed-on: https://chromium-review.googlesource.com/625738
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47504}
TBR=cbruni@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:636391
Change-Id: Iab88ce400f489a677df821d4053bd3678289ae2e
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/637392
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47639}
Optimize the common pattern
for (var i in o) {
if (Object.prototype.hasOwnProperty.call(o, i)) {
// do something
}
}
which is part of the guard-for-in style in ESLint (see the documentation
at https://eslint.org/docs/rules/guard-for-in for details). This pattern
also shows up in React and Ember applications quite a lot (and is tested
by the appropriate Speedometer benchmarks, although not dominating those
benchmarks, since they spent a lot of time in non-TurboFan'ed code).
This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro-
benchmarks in v8:6702, which look like this
function forInHasOwnProperty(o) {
var result = 0;
for (var i in o) {
if (o.hasOwnProperty(i)) {
result += 1;
}
}
return result;
}
function forInHasOwnPropertySafe(o) {
var result = 0;
for (var i in o) {
if (Object.prototype.hasOwnProperty.call(o, i)) {
result += 1;
}
}
return result;
}
by around 4x and allows for additional optimizations in the future, by
also elimiating the megamorphic load when accessing the enumerated
properties.
This changes the interpreter ForInNext bytecode to collect more precise
feedback about the for-in state, which now consists of three individual
states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state
means that the ForInNext has only seen objects with a usable enum cache
thus far, whereas GENERIC means that we have seen some slow-mode for..in
objects as well.
R=jarin@chromium.org
Bug: v8:6702
Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604
Reviewed-on: https://chromium-review.googlesource.com/636964
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47632}
This is so that precise coverage starts with a clean slate.
The old behavior can be emulated by calling getBestEffortCoverage
before starting precise coverage.
R=jgruber@chromium.org
Bug: chromium:757998
Change-Id: Ib3ee2316966f676456198159bdcf8ba8b9d3896f
Reviewed-on: https://chromium-review.googlesource.com/635084
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47629}
- Convert S.p.includes builtin from CPP to TFJ
- Fast paths S.p.includes(str) and S.p.includes(str, smi)
- Add Runtime kStringIncludes
- Add StringIncludesIndexOfAssembler (Generate is based on
StringPrototypeIndexOf builtin)
- S.p.includes and S.p.indexOf both use StringIncludesIndexOfAssembler
Quick measurements show 3x improvement for S.p.includes(str).
More about the measurements: https://gist.github.com/peterwmwong/7a2a96f3171a52f16ca8125a089f38e7
Bug: v8:6680
Change-Id: I79cb8dbe2b79e6df15aa734e128eee25c7e6aaf5
Reviewed-on: https://chromium-review.googlesource.com/620150
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47546}
CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to
allocate very large strings. This CL refactors both methods to use
AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need
to specify explicitly if large-object allocation is possible or not.
Bug: chromium:636391
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f
Reviewed-on: https://chromium-review.googlesource.com/625738
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47504}
Runtime.queryObjects method:
1. force gc,
2. iterate through heap and get all objects with passed constructorName
or with passed constructor name in prototype chain,
3. return these objects as JSArray.
Main use case is regression tests for memory leaks.
R=pfeldman@chromium.org,alph@chromium.org,ulan@chromium.org
Bug: v8:6732
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I52f0803366f14bb24376653615d870a4f21f83e7
Reviewed-on: https://chromium-review.googlesource.com/619594
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47478}
The quite common empty object literal doesn't need an AllocationSite
since it starts off with the general ElementsKind. By using a separate
bytecode we can directly instantiate the empty object without jumping
to the runtime first.
Note: this experimentally disables pretenuring for empty object
literals. Depending on the outcome of our benchmarks pretenuring
will be enabled again or fully removed for empty object literals.
Bug: v8:6211
Change-Id: I2fee81cbefc70865fc436dbd3bc5fc8de04db91c
Reviewed-on: https://chromium-review.googlesource.com/577555
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47467}
This CL is a precursor to the callback-based enumeration of frame summaries.
It removes the reliance of FrameInspector on having a cached copy of the
FrameSummary, instead unpacking it to instance variables so that clients
of FrameInspector do not need to get information from two sources
(the FrameSummary and the FrameInspector itself).
R=yangguo@chromium.org
Bug:
Change-Id: Ib388566c2e1a1147ee0a581323932982a29ae4ff
Reviewed-on: https://chromium-review.googlesource.com/618334
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47420}
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=yangguo@chromium.orgTBR=jarin@chromium.org
Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
This reverts commit 21da12a983.
Reason for revert: Failing on arm64 simulator
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.
Also does some other cleanup:
- Removes CompileUnoptimizedFunction and inlines into new Compiler function
- Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
out of FinalizeUnoptimizedCompile.
BUG=v8:6409
Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
This removes:
- CodeBreakIterator for FCG code.
- RelocModes for debug breaks.
- Code generator for debug break slots.
- GC support for debug break slots.
- Code flag to indicate code with debug break slots.
- Builtin type DBG.
- Mechanisms to replace FCG code in the debugger and LiveEdit.
- Runtime entry to the debugger from debug break slots.
R=bmeurer@chromium.org, rmcilroy@chromium.org, ulan@chromium.org
Bug: v8:6409
Change-Id: I5662c8800e3ef1b1584ad107bfe0aae26c9d8abb
Reviewed-on: https://chromium-review.googlesource.com/613263
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47364}
As long as we have scripts with negative source offset (see inline event listeners) we should not crash a browser when get negative offset.
R=jgruber@chromium.org
Bug: chromium:750592
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic3138e7c61ec0a5133c56de9970acdffa5536d8e
Reviewed-on: https://chromium-review.googlesource.com/611613
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47318}
Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.
Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.
BUG=v8:6409
Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
Splits out AttachOuterScopeInfo from DeclarationScope::Analyze and attaches
the outer scope info after parsing has completed (when parsing on the main
thread, which is the only time we have an outer scope info) instead of
during Compiler::Analyse().
BUG=v8:5203
TBR=yangguo@chromium.org
Change-Id: Idd8d2409fb20f09a9f6bbf5cff7e6edcf90077d7
Reviewed-on: https://chromium-review.googlesource.com/605889
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47243}
As of https://chromium-review.googlesource.com/600968 the CallIC no
longer supports AllocationSite feedback for [[Call]], so we can drop
the TurboFan bits that deal with AllocationSites for JSCall nodes as
well. This further simplifies the handling of the Array constructor.
Drive-by-fix: Rename Builtins::kArrayCode to Builtins::kArrayConstructor
for sake of consistency.
Bug: v8:6399
Change-Id: I9e6a684fc00dd72e25f925db5f407c3f3f715873
Reviewed-on: https://chromium-review.googlesource.com/602354
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47194}
Remove the include of frames.h in isolate.h and the include of
frames-inl.h from various places, e.g. architecture-specific builtin
files.
R=yangguo@chromium.org
Bug:
Change-Id: If8d13188474702fd0b0c298f8e45ef393184b877
Reviewed-on: https://chromium-review.googlesource.com/600212
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47154}
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}
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}
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}
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}
In current implementation we call PrepareForBreakPoints during getting possible breakpoints, this call produce GC and iteration through heap, but it's not needed before we set real breakpoint.
On my machine, get-possible-breakpoints-master.js without CL takes ~200ms, with CL it takes ~60 ms. Running test without getPossibleBreakpoints protocol call takes ~50 ms. It means that we have (200-50)/(60-50) = 15 times faster getPossibleBreakpoints.
R=yangguo@chromium.org,jgrubber@chromium.org
Bug: none
Change-Id: If12e41cd87dbba11a89aa5895e3b4d88123d7d3d
Reviewed-on: https://chromium-review.googlesource.com/591027
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47021}
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}
Now that the maximum string length varies between platforms, the
correctness fuzzer is unhappy. It will ignore crashes, so when we know
we have reached platform-dependant behavior just crash if
--abort_on_stack_overflow is enabled.
Also rename abort_on_stack_overflow to
abort_on_stack_or_string_length_overflow.
Bug: chromium:748137
Change-Id: Ie4e96709b90029b5ce3c8408064d928f841b3b9f
Reviewed-on: https://chromium-review.googlesource.com/589269
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47007}
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}
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 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}
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}
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}
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}
We already have all the functionality available in the
CodeStubAssembler, so this is merely connecting the dots.
Drive-by-fix: Improve code generation for StringCharCodeAt
to properly mark runtime entries as deferred and just use
a single slow-path.
Bug: v8:5049
Change-Id: I76793c823b23f676e65cdb717558473edb6b91cd
Reviewed-on: https://chromium-review.googlesource.com/577533
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46774}
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 makes {NeedsDebugHookCheck} the default for all invocations, as
there is no call-site left that doesn't perform said check. All other
pieces of the {CallWrapper} are dead since Crankshafts removal.
R=jgruber@chromium.org
Change-Id: I158b816c089ede42972e8a7bdfc6ef0c02053a6b
Reviewed-on: https://chromium-review.googlesource.com/577531
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46758}
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}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
Add support for fast
- get Map.prototype.size
- get Set.prototype.size
by porting both the baseline implementation to the CodeStubAssembler and
inlining a fast-path into TurboFan (when the compiler can infer the fact
that the receiver is a proper JSCollection from the surrounding graph,
i.e. from feedback gathered by a dominating LOAD_IC).
R=yangguo@chromium.org
Bug: v8:5269, v8:5717
Change-Id: Ie003fd2551462591273bcb8487b80808dcc6cd82
Reviewed-on: https://chromium-review.googlesource.com/566438
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46555}
This adds a convenience method for the common Smi to int conversion
pattern.
Bug:
Change-Id: I7d7b171c36cfec5f6d10c60f1d9c3e06e3aed0fa
Reviewed-on: https://chromium-review.googlesource.com/563205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46516}
This is the next step towards faster Map and Set iteration. It
introduces the appropriate instance types for Map and Set
iterators (following the pattern for Array iterators) and migrates
the following builtins to the CodeStubAssembler:
- Set.prototype.entries
- Set.prototype.values
- Map.prototype.entries
- Map.prototype.keys
- Map.prototype.values
- %SetIteratorPrototype%.next
- %MapIteratorPrototype%.next
This already provides a significant performance boost for regular
for-of iteration of Sets and Maps, by a factor of 5-10 depending
on the input. The final step will be to inline some fast-paths
into TurboFan.
Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
intrinsics and runtime functions.
TBR=jgruber@chromium.org
Bug: v8:6344, v8:6571, chromium:740122
Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
Reviewed-on: https://chromium-review.googlesource.com/563626
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46497}
This reverts commit 3f22832be7.
Reason for revert: Layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849
Original change's description:
> [builtins] Port Map and Set iterators to CodeStubAssembler.
>
> This is the next step towards faster Map and Set iteration. It
> introduces the appropriate instance types for Map and Set
> iterators (following the pattern for Array iterators) and migrates
> the following builtins to the CodeStubAssembler:
>
> - Set.prototype.entries
> - Set.prototype.values
> - Map.prototype.entries
> - Map.prototype.keys
> - Map.prototype.values
> - %SetIteratorPrototype%.next
> - %MapIteratorPrototype%.next
>
> This already provides a significant performance boost for regular
> for-of iteration of Sets and Maps, by a factor of 5-10 depending
> on the input. The final step will be to inline some fast-paths
> into TurboFan.
>
> Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
> intrinsics and runtime functions.
>
> Bug: v8:6571, chromium:740122
> Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
> Reviewed-on: https://chromium-review.googlesource.com/563399
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46492}
TBR=jgruber@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6571, chromium:740122
Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07
Reviewed-on: https://chromium-review.googlesource.com/564419
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46495}
This is the next step towards faster Map and Set iteration. It
introduces the appropriate instance types for Map and Set
iterators (following the pattern for Array iterators) and migrates
the following builtins to the CodeStubAssembler:
- Set.prototype.entries
- Set.prototype.values
- Map.prototype.entries
- Map.prototype.keys
- Map.prototype.values
- %SetIteratorPrototype%.next
- %MapIteratorPrototype%.next
This already provides a significant performance boost for regular
for-of iteration of Sets and Maps, by a factor of 5-10 depending
on the input. The final step will be to inline some fast-paths
into TurboFan.
Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
intrinsics and runtime functions.
Bug: v8:6571, chromium:740122
Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
Reviewed-on: https://chromium-review.googlesource.com/563399
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46492}
This adds a new binary block coverage mode (in addition to the existing count
block coverage), as well as a few transformation passes to reduce the number of
uselessly reported ranges.
Bug: v8:6000
Change-Id: I4fb234ca015990d00aa2f1dccb87f76ba4748994
Reviewed-on: https://chromium-review.googlesource.com/552642
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46463}
This CL adds a few transformations that clean up the set of reported
source ranges. Duplicates, empty, and uncovered ranges are removed, and
nested/consecutive ranges are merged if possible.
BUG=v8:6000
Change-Id: I421ee35ce8292cfe84c1eea4f653762cea5d909d
Reviewed-on: https://chromium-review.googlesource.com/558411
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46450}
This is the first step in optimizing Map and Set iterators. This ports
all the base functionality including
- Set.prototype.entries
- Set.prototype.values
- %SetPrototypeIterator%.next
- Map.prototype.entries
- Map.prototype.keys
- Map.prototype.values
- %MapPrototypeIterator%.next
to C++ and removes all the dead code and the previous half JavaScript
implementation. The next step is to port core parts to CodeStubAssembler
and finally inline the fast-paths into TurboFan directly. The relevant
design document is at:
https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8
Most of this work is very similar to how the Array iterator works and we
mostly follow the same process for the implementation.
R=jgruber@chromium.org
Bug: v8:6571
Change-Id: Ieb253d6705ba4077c697a5ff0cb6f87f9c4056ff
Reviewed-on: https://chromium-review.googlesource.com/561138
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46441}
It can happen that coverage infos for a function containing
IncBlockCounter bytecodes can be deleted (e.g. by switching to
best-effort coverage). Handle this case correctly in the IncBlockCounter
runtime function.
BUG=v8:6000
Change-Id: I49b9f52822661150d55410d6b173b3929adf4af2
Reviewed-on: https://chromium-review.googlesource.com/558039
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46351}
There are very few cases where OSR code can be re-used, and where the
function won't be non-concurrently optimized after OSR has happened.
Maintaining the OSR code cache is unnecessary complexity, and caching
OSR prevents us from e.g. seeding the optimizer with the actual OSR
values.
So, this patch removes it.
Change-Id: Ib9223de590f35ffc1dc2ab593b7cc9fe97dde4a6
Reviewed-on: https://chromium-review.googlesource.com/552637
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46306}
icu-case-mapping was shipped a few months ago. By dropping
the flag, unibrow's case conversion code won't be included
by default because V8_INTL_SUPPORT is on by default.
BUG=v8:4477, v8:4476
TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*,
mjsunit/string-case, intl/general/case*
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I78be9cc64b4588bc5af79ecbbadf93af6e84a1df
Reviewed-on: https://chromium-review.googlesource.com/534541
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46304}
This CL replaces usages of utils.InstallFunctions and utils.InstallGetter()
with utils.InstallConstants(). Since these methods are not exposed to the user it
doesn't matter if we add them with DONT_ENUM attributes or not.
This CL is one of a series of cleanup CL which are the preliminary steps for
improving function closures creation.
Bug: v8:6459
Change-Id: I41708741f1cc013e4f4c37f1c7a73c1333deca7d
Reviewed-on: https://chromium-review.googlesource.com/548137
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46288}
This piggy-backs on top of existing precise and best-effort coverage to expose
block coverage through the inspector protocol.
Coverage collection now implicitly reports block-granularity coverage when
available. A new 'isBlockCoverage' property on Inspector's FunctionCoverage
type specifies the granularity of reported coverage.
For now, only count-based block coverage is supported, but binary block
coverage should follow soon.
Support is still gated behind the --block-coverage flag.
Bug: v8:6000
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I9c4d64e1d2a098e66178b3a68dcee800de0081af
Reviewed-on: https://chromium-review.googlesource.com/532975
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46157}
This CL improves reported source range precision in a couple of ways:
Source ranges are now standardized to consist of an inclusive start
index and an exclusive end index (similar to what's reported for
functions). For example:
0123456789 // Offset.
{ f(); } // Block represented as range {0,8}.
Duplicate singleton ranges (i.e. same start and end offsets) are now
merged (this only becomes relevant once jump statement coverage is
added). For example:
for (.) break; // Break- and loop continuation have same positions.
SourceRangeScope incorrectly collected starting position
(unconditionally) and end position (when no semi-colon was present).
01234567890123 // Offset.
for (.) break // Loop body range is {8,13}, was {6,9}.
Bug: v8:6000
Change-Id: I62e7c70cc894a20f318330a2fbbcedc47da2b5db
Reviewed-on: https://chromium-review.googlesource.com/541358
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46095}
Inspector uses only BREAK_POSITION_ALIGNED, no tests pass STATEMENT_ALIGNED. It's exposed only with debugger API but I'm pretty sure that nobody actually uses it and as far as mirrors API is deprecated - it's time to remove it.
R=jgruber@chromium.org
Bug: none
Change-Id: I28d62e145811d3eb6f4d64007c47c51b2ecbaf0f
Reviewed-on: https://chromium-review.googlesource.com/536934
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46056}
Track execution counts of the continuations of block structures (e.g.
IfStatements) to capture cases in which execution does not continue after a
block. For example:
for (;;) {
return;
}
// Never reached, tracked by continuation counter.
A continuation counter only has a start position; it's range is implicitly
until the next sibling range or the end of the parent range.
Bug: v8:6000
Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70
Reviewed-on: https://chromium-review.googlesource.com/530846
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46006}
I incorrectly assumed that ScopeIterator::SetModuleVariableValue gets called
when the frame is the module function.
R=jgruber@chromium.org, kozyatinskiy@chromium.org
Bug: v8:1569, v8:6484
Change-Id: I1fbad8ccde57280149547c78e679527f7a0c89dd
Reviewed-on: https://chromium-review.googlesource.com/535620
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45961}
Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.
This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code
A.prototype.isPrototypeOf(a)
is now performance-wise on par with
a instanceof A
for the case where A is a regular constructor function and a is an
instance of A.
Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.
This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}
console.context(name:string) method returns console instance, this console instance fully implements console interface (including fact that any method can be called without console as receiver).
Protocol.Runtime.consoleAPICalled notification contains additional context:string field:
- "anonymous#unique-id" for any method call on unnamed console context,
- "name#unique-id" for any method call on named console context.
console.count and console.timeEnd have context as a scope.
console.clear clear all messages regardless on what context instance it was called.
console calls is ~10% slower with this CL since we need to store and then fetch console_context_id and console_context_name from function object.
We recently (in April) made console calls twice faster so 10% doesn't sound critical and existing of console.log call in hot code is problem by itself.
R=pfeldman@chromium.org
Bug: chromium:728767
Change-Id: I5fc73216fb8b28bfe1e8c2c1b393ebfbe43cd02e
Reviewed-on: https://chromium-review.googlesource.com/522128
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45864}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
Store 'length' and 'formal_parameter_count' fields as raw ints.
Also fixed a couple of issues on the way.
TBR=verwaest@chromium.org
Bug: v8:6470
Change-Id: I74ecd87cb0f041e61dab50d8bc29e3604dd1d09c
Reviewed-on: https://chromium-review.googlesource.com/527156
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45774}
BytecodeArrayBreakIterator doesn't iterate through locations in position() order. SkipToPosition is looking for closest break_index to passed one. So we should iterate through all breakable locations in function to get all of them.
R=jgruber@chromium.org
Bug: v8:6469
Change-Id: Ida0b849e9df40458a13e0a0f7af6a00349088228
Reviewed-on: https://chromium-review.googlesource.com/527135
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45765}
Adds support for lowering of ToPrimitiveToString and StringConcat bytecodes
to the corresponding builtins. As part of this, moves the interpreter
implementation of these operations into the appropriate builtin generators
and add builtin support for them.
Also adds TailCallRuntimeN operator to code-assembler which enables tail calling
a runtime function when the arguments have already been pushed onto the stack.
BUG=v8:6243
Change-Id: Id5c851bc42e4ff490d9a23a8990ae331c7eac73e
Reviewed-on: https://chromium-review.googlesource.com/515362
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45756}
Properly propagate the fact that the function has a statically known name from
parser to SharedFunctionInfo objects. The empty string that has been set as
name before this CL does not help to distinguish cases like:
var o1 = { ''(){} };
var o1 = { [foo()](){} };
or
var o2 = { get ''(){} };
var o2 = { get [foo()](){} };
This is a preliminary step for using different layouts for closure objects with
and without computed names.
TBR=bmeurer@chromium.org, marja@chromium.org
Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
Reviewed-on: https://chromium-review.googlesource.com/522073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45744}
This CL implements general infrastructure for block coverage together with
initial support for if-statements.
Coverage output can be generated in lcov format by d8 as follows:
$ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
$ genhtml ~/simple-if.lcov -o ~/simple-if
$ chrome ~/simple-if/index.html
A high level overview of the implementation follows:
The parser now collects source ranges unconditionally for relevant AST nodes.
Memory overhead is very low and this seemed like the cleanest and simplest
alternative.
Bytecode generation uses these ranges to allocate coverage slots and insert
IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
for if-statements). The slot-range mapping is generated here and passed on
through CompilationInfo, and is later accessible through the
SharedFunctionInfo.
The IncBlockCounter bytecode fetches the slot-range mapping (called
CoverageInfo) from the shared function info and simply increments the counter.
We don't collect native-context-specific counts as they are irrelevant to our
use-cases.
Coverage information is finally generated on-demand through Coverage::Collect.
The only current consumer is a d8 front-end with lcov-style output, but the
short-term goal is to expose this through the inspector protocol.
BUG=v8:6000
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2882973002
Cr-Commit-Position: refs/heads/master@{#45737}
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole
/ ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
In the bytecode-graph builder they are handled by introducing a deopt point
instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
bytecodes are removed since they are no longer required.
Bug: v8:4280, v8:6383
Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
Reviewed-on: https://chromium-review.googlesource.com/509613
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
DebugInfo was very closely tied to break point support:
* It contained only information relevant to break points.
* It was created and freed by break point implementation.
* Existence of a DebugInfo on the shared function info implied existence of
break points.
This CL is a step towards making DebugInfo usable by other debugging
functionality such as block coverage by decoupling it from break point support,
which is now only one kind of information stored on the DebugInfo object.
BUG=v8:6000
Review-Url: https://codereview.chromium.org/2909893002
Cr-Commit-Position: refs/heads/master@{#45640}
V8 provides ScriptCompiler::CompileFunctionInContext method which takes expression and compile it as anonymous function like (function() .. expression ..). To produce correct locations for stmts inside of this expression V8 compile this function with negative offset. Instead of stmt position blackboxing use function start position which is negative in described case.
Bug: chromium:705963
Change-Id: I86b113198fb59e77b3bbf523c8cd943e22f8a6ca
Reviewed-on: https://chromium-review.googlesource.com/519384
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45637}
This is consistent with C++ memory model and avoids confusion with GC
write barrier.
BUG=
Review-Url: https://codereview.chromium.org/2912773002
Cr-Commit-Position: refs/heads/master@{#45584}
In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume.
The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change.
I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit.
Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish.
BUG=v8:6368
Review-Url: https://codereview.chromium.org/2898163002
Cr-Commit-Position: refs/heads/master@{#45515}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246,chromium:718891
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6
Reviewed-on: https://chromium-review.googlesource.com/500134
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45234}
This reverts commit 662aa425ba.
Reason for revert: Crashing on Canary
BUG=chromium:718891
Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
>
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246
Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
The collection builtins (Map, Set, WeakMap, WeakSet) are still written
in JavaScript and make heavy use of %_ClassOf, which is kind of
expensive compared to a simple instance type check. Change that to use
simple instance type checks instead.
R=jarin@chromium.org
BUG=v8:6261,v8:6278,v8:6344
Review-Url: https://codereview.chromium.org/2814773005
Cr-Original-Commit-Position: refs/heads/master@{#45106}
Committed: 28170099fd
Review-Url: https://codereview.chromium.org/2814773005
Cr-Commit-Position: refs/heads/master@{#45124}
The collection builtins (Map, Set, WeakMap, WeakSet) are still written
in JavaScript and make heavy use of %_ClassOf, which is kind of
expensive compared to a simple instance type check. Change that to use
simple instance type checks instead.
R=jarin@chromium.org
BUG=v8:6261,v8:6278,v8:6344
Review-Url: https://codereview.chromium.org/2814773005
Cr-Commit-Position: refs/heads/master@{#45106}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
This reverts commit c5ad9c6d8e.
Reason for revert: Fails on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661
Original change's description:
> [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
>
> Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
> Reviewed-on: https://chromium-review.googlesource.com/476891
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45022}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6246
Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619
Reviewed-on: https://chromium-review.googlesource.com/493287
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45027}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
Reviewed-on: https://chromium-review.googlesource.com/476891
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45022}
This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.
Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.
Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.
This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}
Until now JIC and JIALC compact branches were emited without using their
offset. Here we optimize their use by using offset after addition and/or
load immediate operations.
The CL also fixes a problem with deserialization that occurs when a code
object ends with an optimized LUI/AUI and JIC/JIALC instruction pair.
Deserializer processed these instruction pairs by moving to a location
immediately after it, but when this location is the end of the object it
would finish with the current object before doing relocation. This is
fixed by moving the deserializer one instruction before the location of
the instruction pair end.
BUG=
Review-Url: https://codereview.chromium.org/2542403002
Cr-Commit-Position: refs/heads/master@{#44841}
With recent CLs we always store maximum N async stack traces and when we reach limit we drop half of them.
Current promise collected event requires creating weak handle:
- it takes time,
- it consumes memory.
Since async task id distribution for promises is uniform (each new promise has last_async_task_id + 1 as an id) our hash map is good enough to handle any amount of async task ids, following time of executing 1 000 000 000 of lookups:
- for empty hash map: 1.45 seconds,
- for hash map with one entry: 14.95 seconds
- 1024 entries: 15.03 seconds
- 1024 * 1024 entries: 14.82 seconds
- 1024 * 1024 * 1024: 17.9 seconds
BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2819423005
Cr-Commit-Position: refs/heads/master@{#44750}
For MIPS64, many load/store operations from/to memory emit more then
one instruction. This is the reason for moving them from assembler to
macro-assembler.
TEST=
BUG=
Review-Url: https://codereview.chromium.org/2829073002
Cr-Commit-Position: refs/heads/master@{#44746}
What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:6175
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#44353}
Committed: 55905f85d6
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Commit-Position: refs/heads/master@{#44355}
Committed: cc74ea0bc4
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Commit-Position: refs/heads/master@{#44416}
Committed: f5dc738cda
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44702}
The biggest problem is isolate.h (this CL doesn't solve that yet).
BUG=v8:5294
Change-Id: I56b32109f501c48facd99cd12ca6c8f427e188a9
Reviewed-on: https://chromium-review.googlesource.com/471487
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44613}
This relands commit d3e9aade0f. The original CL was reverted speculatively but didn't cause the buildbot failure.
Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
>
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
>
> In the process, adds Smi bytecode variants for all binary operations, adding
> - MulSmi
> - DivSmi
> - ModSmi
> - BitwiseXorSmi
> - ShiftRightLogical
>
> BUG=v8:6194
>
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}
TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6194
Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8
Reviewed-on: https://chromium-review.googlesource.com/472746
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44511}
This reverts commit d3e9aade0f.
Reason for revert: Speculative for:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/4449
Bisect points to this CL.
Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
>
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
>
> In the process, adds Smi bytecode variants for all binary operations, adding
> - MulSmi
> - DivSmi
> - ModSmi
> - BitwiseXorSmi
> - ShiftRightLogical
>
> BUG=v8:6194
>
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,ishell@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6194
Change-Id: If57dbdbe40be77804bf437463b855d3167e2d473
Reviewed-on: https://chromium-review.googlesource.com/471308
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44488}
Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
literals in the BytecodeGenerator. This enables us to perform the
transformation for literals on either side for commutative operations, and
Avoids having to do the check on every bytecode in the peephole optimizer.
In the process, adds Smi bytecode variants for all binary operations, adding
- MulSmi
- DivSmi
- ModSmi
- BitwiseXorSmi
- ShiftRightLogical
BUG=v8:6194
Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
Reviewed-on: https://chromium-review.googlesource.com/466246
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44477}
What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.
BUG=v8:6175
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Commit-Position: refs/heads/master@{#44353}
Committed: 55905f85d6
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Commit-Position: refs/heads/master@{#44355}
Committed: cc74ea0bc4
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44416}
Move the ToBoolean elision in the BytecodeGenerator instead of the
peephole optimizer. Adds a TypeHint mechanism to the ExpressionResult
to enable passing of type hints through the ast visitor.
BUG=v8:6194
Change-Id: Ic55506ba11b213f7459250004d3f18cab04ee9b3
Reviewed-on: https://chromium-review.googlesource.com/467208
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44415}
Reason for revert:
http://crbug.com/v8/6198
Original issue's description:
> [inspector] move console to builtins
>
> What will we get:
> - console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
> - it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
> - console calls are ~ 15% faster.
>
> BUG=v8:6175
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2785293002
> Cr-Original-Commit-Position: refs/heads/master@{#44353}
> Committed: 55905f85d6
> Review-Url: https://codereview.chromium.org/2785293002
> Cr-Commit-Position: refs/heads/master@{#44355}
> Committed: cc74ea0bc4TBR=dgozman@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6175
Review-Url: https://codereview.chromium.org/2790343002
Cr-Commit-Position: refs/heads/master@{#44358}
What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.
BUG=v8:6175
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Commit-Position: refs/heads/master@{#44353}
Committed: 55905f85d6
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44355}
Reason for revert:
console.toString() should return "[object Object]"
Original issue's description:
> [inspector] move console to builtins
>
> What will we get:
> - console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
> - it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
> - console calls are ~ 15% faster.
>
> BUG=v8:6175
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2785293002
> Cr-Commit-Position: refs/heads/master@{#44353}
> Committed: 55905f85d6TBR=dgozman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6175
Review-Url: https://codereview.chromium.org/2795003003
Cr-Commit-Position: refs/heads/master@{#44354}
What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.
BUG=v8:6175
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44353}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: I0a3546618d01b9232014da94cf8d0f72427a0d1d
Reviewed-on: https://chromium-review.googlesource.com/458006
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44176}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: I977eec8faecc8a112506f219994b4e4ec388b180
Reviewed-on: https://chromium-review.googlesource.com/458004
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44160}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: Iefd2fd01a700509f05d6f1a272cfa39cc545d39b
Reviewed-on: https://chromium-review.googlesource.com/458001
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#44096}
With precise binary code coverage, the reported count is either 0 or 1.
We only report 1 the first time we collect coverage data after the
function has been executed.
Since we do not care about the accurate execution count, we can optimize
the function once it has been executed once.
Also change best effort coverage to be implicitly binary.
R=caseq@chromium.org, jgruber@chromium.org, pfeldman@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2766573003
Cr-Commit-Position: refs/heads/master@{#44074}
Proposed behaviour:
- StepNext at return position go into next function call (no changes with current behavior, but implemented in v8::Debug instead of hack on inspector side);
- StepOut at return position go into next non-current function call.
We need this to have better stepping in cases with native functions, blackboxed functions and/or different embedder calls (e.g. event listeners).
New behavior could be illustrated with two examples (for more see stepping-with-natives-and-frameworks test):
- let's assume that we've blackboxed callAll function, this function just takes its arguments and call one after another:
var foo = () => 1;
callAll(foo, foo, () => 2);
If we break inside of first call of function foo. Then on..
..StepNext - we're able to reach second call of function foo,
..StepOut - we're able to reach () => 2 call.
- let's consider case with native function:
[1,2,3].map(x => x * 2)
If we break inside of first callback call, then with StepNext we can iterate through all calls of callback, with StepOut we go to next statement after .map call.
Implementation details:
- when we request break we schedule step-in function call for any step action at return position and for step-in at any position,
- when we request StepOut at return position - we mark current function as needed-to-be-ignored inside of PrepareStepIn(function) call,
- when we request StepOut at not return position - we set break at return position and ask debugger to just repeat last step action on next stepping-related break.
Design doc: https://docs.google.com/document/d/1ihXHOIhP_q-fJCA0e2EiXz_Zr3B08KMjaPifcaqZ60Q/edit
BUG=v8:6118,chromium:583193
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2758483002
Cr-Commit-Position: refs/heads/master@{#44028}
The old method always returned a Handle<Object>, requiring an explicit
cast in the caller. This CL makes it return Handle<T> if called with a
T* as parameter.
Also, remove now redundant casts from callers.
R=bmeurer@chromium.org
Change-Id: I13cfb2f2e812e8582a9a1d9d6c8a5a24f40d0e79
Reviewed-on: https://chromium-review.googlesource.com/458376
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44012}
We used to clear invocation counts when enabling precise coverage.
This is not necessary, and we could continue to use the existing
invocation counts on the heap. The old behavior can be achieved
by explicitly resetting the counts by polling coverage data.
R=jgruber@chromium.org,caseq@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2768453002
Cr-Commit-Position: refs/heads/master@{#43964}
Also add tests for operators.
BUG=v8:5821
Change-Id: I76cfde94324c7f05de61cb60f26d5168da0a9aa5
Reviewed-on: https://chromium-review.googlesource.com/456500
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43922}
Default to the chromium-internal build config (instead of the more
permissive no_chromium_code config).
BUG=v8:5878
Review-Url: https://codereview.chromium.org/2758563002
Cr-Commit-Position: refs/heads/master@{#43909}
This CL renames all occurrences of "internal field" to "embedder field"
to prevent confusion. As it turns out, these fields are not internal to
V8, but are actually embedder provided fields that should not be mucked
with by the internal implementation of V8.
Note that WASM does use these fields, and it should not.
BUG=v8:6058
Review-Url: https://codereview.chromium.org/2741683004
Cr-Commit-Position: refs/heads/master@{#43900}
This is a first step towards moving Turbofan code generation off the main thread.
Summary of the changes:
- AssemblerBase no longer has a pointer to the isolate. Instead, its
constructor receives the few things that it needs from the isolate (on most
architectures this is just the serializer_enabled flag).
- RelocInfo no longer has a pointer to the isolate. Instead, the functions
that need it take it as an argument. (There are currently still a few that
implicitly access the isolate through a HeapObject.)
- The MacroAssembler now explicitly holds a pointer to the isolate (before, it
used to get it from the Assembler).
- The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
it's not used at all in the Assemblers.
- A few architectures implemented parts of the Assembler with the help
of a Codepatcher that is based on MacroAssembler. Since the Assembler no
longer has the isolate, but the MacroAssembler still needs it, this doesn't
work anymore. Instead, these Assemblers now use a new PatchingAssembler.
BUG=v8:6048
Review-Url: https://codereview.chromium.org/2732273003
Cr-Commit-Position: refs/heads/master@{#43890}
This reverts the previous revert, commit
5a04f4fd68.
Previously reverted changes:
> Revert "[SAB] Move Atomics builtins to C++"
>
> This reverts commit 2b9840d86f.
>
> Revert "[SAB] Remove unreachable Uint8Clamped atomics paths"
>
> This reverts commit d1160fb14f.
>
> Revert "Remove tiny unit test for MinSimple/MaxSimple"
>
> This reverts commit 837760ecb7.
>
> Revert "Remove infrastructure for experimental JS natives"
>
> This reverts commit 8cfe45b6f1.
These changes were reverted to improve a perf regression on a Chrome
bot. Since then, the regression has reappeared, then disappeared again
all from seemingly unrelated changes.
BUG=v8:6033
TBR=adamk@chromium.org,hpayer@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2732213005
Cr-Commit-Position: refs/heads/master@{#43758}
We emulate break by callling breakProgramCallback function in debugger context, we can just use HandleDebugBreak.
It allows us to move all stepping logic to debug.cc later and remove one usage of debugger context.
+ two minor issues fixed, see tests.
BUG=v8:5510
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2738503006
Cr-Commit-Position: refs/heads/master@{#43750}
In the process, re-factor the implementation of Array.prototype.forEach so that
the bulk of the implementation can be re-used, since much of the spec is
identical. The refactor should also make it more straight-forward to implement
map and filter. The re-factored version only have a single slow path for processing
elements which is used for both the overall slow path and for the bailout from the
FAST_ELEMENTS case.
Review-Url: https://codereview.chromium.org/2709773002
Cr-Commit-Position: refs/heads/master@{#43745}
BUG=
Change-Id: Ibf49df830153a829015723826dacc6939fb42189
Reviewed-on: https://chromium-review.googlesource.com/452377
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43689}
If the top-level function cannot be found, we previously assumed an
invocation count of 1. This is wrong when we expect the invocation
counts to be reset for precise coverage.
TBR=jgruber@chromium.orgR=caseq@chromium.org,pfeldman@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2723003007
Cr-Commit-Position: refs/heads/master@{#43620}
This CL provide type with each break location, type could be: call, return or debugger statement.
BUG=chromium:432469
R=yangguo@chromium.org,dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2728563002
Cr-Commit-Position: refs/heads/master@{#43619}
This method could be called on pause and will do stepInto next scheduled callback if any will happen until next break.
First implementation support only callbacks chained by Promise.prototype.then.
BUG=chromium:432469
R=yangguo@chromium.org,dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2723273002
Cr-Commit-Position: refs/heads/master@{#43616}
The x64 side is included in https://chromium-review.googlesource.com/c/444226/
BUG=v8:5294
Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}
perf regression. See crbug.com/695653 for more info.
Revert "[SAB] Move Atomics builtins to C++"
This reverts commit 2b9840d86f.
Revert "[SAB] Remove unreachable Uint8Clamped atomics paths"
This reverts commit d1160fb14f.
Revert "Remove tiny unit test for MinSimple/MaxSimple"
This reverts commit 837760ecb7.
Revert "Remove infrastructure for experimental JS natives"
This reverts commit 8cfe45b6f1.
BUG=695653
TBR=hablich@chromium.org
Review-Url: https://codereview.chromium.org/2715223003
Cr-Commit-Position: refs/heads/master@{#43462}
Now that no harmony-flagged features are implemented in experimental
JS, most of this is simply dead code.
As PostExperimentals() is no longer needed, I also removed the use of
Import() in the debug context, allowing the deletion of PostDebug()
along with PostExperimentals(); cleanup code is moved to the
end of PostNatives.
Also gets rid of some longer-dead code in prologue.js related to
TypedArrays, and some duplicate code for setting up SharedArrayBuffer
builtins.
Review-Url: https://codereview.chromium.org/2705293004
Cr-Commit-Position: refs/heads/master@{#43418}
