Things that don't work yet:
(a) pre parsed scope data is broken
(b) private fields can be accessed outside classes
(c) no early or runtime error for accessing unknown fields
Things that do work:
everything else
Change-Id: I3d58be44e2be73ec50defb42403112a8a5e68c54
Bug: v8:5368
Reviewed-on: https://chromium-review.googlesource.com/865497
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50935}
This adjusts the RunMicrotask logic to invoke CallHandlerInfo microtasks
from CSA land directly (via a runtime function call), instead of bailing
out to C++ for the rest of the microtask queue entries. Even in simple
micro-benchmarks there doesn't seem to be a huge performance difference.
In fact performance get's better when CallHandlerInfo and promises are
mixed, which makes sense, since calling from C++ to JS land is more
expensive than the other way around.
But just in case the runtime function call overhead ever becomes the
bottleneck we can introduce a direct C++ call and setup a handle scope
around it, much like a very simple version of CallApiFunctionStub.
This greatly simplifies the microtask handling and paves the way for
refactoring the queue to significant reduce the GC overhead associated
with promises currently.
Bug: v8:7253
Change-Id: I33adb62a6bada138674d324f36d4be894e27f3c9
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890441
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50934}
The @@species protector guards the following (in case of Promises):
- The initial Promise.prototype has the initial "constructor"
pointing to the Promise constructor.
- No JSPromise instance has a "constructor" property.
So this is sufficient to guard the fast-path in PromiseResolve, given
that we check whether the value is actually a JSPromise and that the
[[Prototype]] of value is the (initial) Promise.prototype.
Also refactor the code a bit and avoid the BranchIfSameValue, which
blows up the builtin quite a lot, since we already know that constructor
must be a valid JSReceiver and thus we can simply use WordEqual to
compare value's "constructor" to the constructor.
Bug: v8:7253
Change-Id: I6413882241c9648c95bb2299100a6c3a7c803110
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890438
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50933}
We were starting an allocation step during NewSpace::AddFreshPage. At
this point, we had advanced the page, but not updated allocation_info_.
This ultimately led to assertions as Space::Size was not expecting
to be called when to_space_.page_{high,low} are inconsistent with
allocation_info_.top().
The solution here is to avoid starting the step in the middle of the
space state mutation. We account for memory allocated so far before the
mutation is started, and then start a new step after the mutation has
been completed.
Bug: chromium:806179
Change-Id: I17ee896d80c4ec752baa2b17c3fd2bef7ea2ca33
Reviewed-on: https://chromium-review.googlesource.com/889981
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50932}
Even though most compilers accept the method to be private, gcc 4.8
complains about this (which seems to be correct). Thus we make this
method protected.
R=franzih@chromium.org
Change-Id: Ia49b2ddebe1ced7529d4943107a76a909c355b73
Reviewed-on: https://chromium-review.googlesource.com/890449
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50931}
This adds back an option for interrupt budget available in no-snap
builds. This also adds a fuzzer configuration for numfuzz that enables
fuzzing the interrupt budget option. A new flag --disable-analysis
allows to generally skip the fuzzer's analysis phase, which can be
chosen for interrupt budget, which doesn't support an analysis phase.
Bug: v8:6917
Change-Id: I546dd9ee41c3e0fb027108ef4606a34514f230d4
Reviewed-on: https://chromium-review.googlesource.com/885805
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50929}
This reverts commit 8a27c7d396.
Reason for revert:
Having more tasks then work items is intentional in some use cases, i.e. Scavenging where RunInParallel() does parallel processing on a dynamic workload *after* the initial set of work items:
{
barrier_->Start();
TimedScope scope(&scavenging_time);
PageScavengingItem* item = nullptr;
while ((item = GetItem<PageScavengingItem>()) != nullptr) {
item->Process(scavenger_);
item->MarkFinished();
}
do {
scavenger_->Process(barrier_);
} while (!barrier_->Wait());
scavenger_->Process();
}
Original change's description:
> v8::ItemParallelJob : Do not launch more Tasks than there are Items to process.
>
> Except when there are 0 items. For some reason I don't quite understand yet, not
> calling Run() on tasks_[0] when there are 0 items results in DCHECKs...
>
> Bug: chromium:806237
> Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
> Reviewed-on: https://chromium-review.googlesource.com/888704
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50924}
TBR=gab@chromium.org,mlippautz@chromium.org
Change-Id: Iad2ab16bb41f339de8e3fbca1c08c5d26b8a0111
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:806237
Reviewed-on: https://chromium-review.googlesource.com/891186
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50928}
This is the first step for retiring swarming tests with gyp.
TBR=sergiyb@chromium.org
NOTRY=true
Bug: v8:7335
Change-Id: I98145843b91d47a77e06173c2a421fcc0d4e5586
Reviewed-on: https://chromium-review.googlesource.com/891230
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50927}
Except when there are 0 items. For some reason I don't quite understand yet, not
calling Run() on tasks_[0] when there are 0 items results in DCHECKs...
Bug: chromium:806237
Change-Id: I38c8fffde64a42f93f4efda492832651137eebd7
Reviewed-on: https://chromium-review.googlesource.com/888704
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50924}
Wide suspends have a "wide" (or "extra-wide") bytecode at their offset,
rather than the suspend itself, so they were failing the return check.
Bug: chromium:805765
Change-Id: Iabfc2a2167d09eda2f6885d9100287aadcd8fee9
Reviewed-on: https://chromium-review.googlesource.com/887082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50923}
There is currently no test that shows this bug (it was found as part of the DSL
experiment), but it should get fixed anyway and it will eventually be verified
by the A.p.splice CSA builtin port that is in progress.
Change-Id: I9b6da8dc8f3151ad0b0a06c3ca10d604060efef7
Reviewed-on: https://chromium-review.googlesource.com/890580
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50921}
This makes the ArrayBuiltinsAssembler consistent with the StringBuiltinsAssembler
and paves the way for tools that expect the assemblers to have a common structure.
Change-Id: I7470fc2cf144f9cc2fdbcee99b31daed267550be
Reviewed-on: https://chromium-review.googlesource.com/889933
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50920}
Without realm-eval, the toplevel references in loaded tests are not
garbage-collected and changes in the tests can affect the global
object.
TBR=ulan@chromium.org
NOTRY=true
Bug: v8:7379, v8:7376
Change-Id: Id4d451e38fe49c6531a07d541ad3c67298b6acf2
Reviewed-on: https://chromium-review.googlesource.com/890519
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50915}
import() is shipping by default in Chrome 63 and import.meta is
shipping in Chrome 64 already.
The flag still exists so that embedders can turn off the feature
if required.
Bug: v8:5785, v8:6693
Change-Id: Ie6c8f90927958022900f677ea5a771527111aece
Reviewed-on: https://chromium-review.googlesource.com/889658
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50913}
These assertions would have caught the bug closer to the source.
BUG=v8:7313
Change-Id: I19b75c3fc7bff8216dda370114ff00326f128116
Reviewed-on: https://chromium-review.googlesource.com/887175
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50910}
Don't start new steps recursively if a step is already in progress.
Having this property on a space is not sufficient, as an allocation
is a global (heap-wide) event. Computing the next step size, for example
is a property of all observers in existence rather than the spaces in
existence.
In this case a failure was due to the fact that we attempted to compute
the next step size while a given observer was mid-way through its step
triggered from a different space. bytes_to_next_step_ was partially
updated at that point.
BUG=v8:7313
Change-Id: Iaf632fce2cfd5ed49b0f41a69c3694e505e17d81
Reviewed-on: https://chromium-review.googlesource.com/887174
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50909}
This ensures that i32 values which are loaded into 64 bit registers
have the upper 32 bits cleared.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I5eb2b65ac079b5683c83d755b1aa4a626411d5d4
Reviewed-on: https://chromium-review.googlesource.com/888702
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50907}
This CL uses UTF16 encoding internally in the string iterator,
thereby saving a few shifts, ors, and ands.
Bug: v8:7270
Change-Id: I3ac9e0e8c4b64eb1d6c796597eb0b3413c5f516b
Reviewed-on: https://chromium-review.googlesource.com/887085
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50904}
They have been replaced with num_fuzzer.
Bug: v8:6917
Change-Id: I2f78df308cec0a58f0d665bce82503dee68fcebc
Reviewed-on: https://chromium-review.googlesource.com/888641
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#50903}
This is a reland of 8f4407fbd6.
Original change's description:
> [test] Keep the order of variants
>
> Bug: v8:6917
> Change-Id: I7e04255649f62a28f0ed07ccb4fbaf4825498bf6
> Reviewed-on: https://chromium-review.googlesource.com/886841
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50874}
Bug: v8:6917
Change-Id: I9d4c617ccec6db8929af3095f2f27d8964c5d6b8
Reviewed-on: https://chromium-review.googlesource.com/888582
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michał Majewski <majeski@google.com>
Cr-Commit-Position: refs/heads/master@{#50901}
Passing --trace_duplicate_threshold_kb=XX will print stats about
duplicates on the heap in Heap::CollectAllAvailableGarbage function.
One way to trigger the tracing is to force GC in DevTools.
Change-Id: I535ae202c796c3dcf7262a0d0bfd2702f44ac27a
Reviewed-on: https://chromium-review.googlesource.com/888746
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50896}
This reverts commit 8f4407fbd6.
Reason for revert: Failing in old test runner. See comment.
Original change's description:
> [test] Keep the order of variants
>
> Bug: v8:6917
> Change-Id: I7e04255649f62a28f0ed07ccb4fbaf4825498bf6
> Reviewed-on: https://chromium-review.googlesource.com/886841
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50874}
TBR=machenbach@chromium.org,sergiyb@chromium.org,majeski@google.com
Change-Id: Ia8608053e080c70d2ac09d7921a6abb6cd0e338f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6917
Reviewed-on: https://chromium-review.googlesource.com/888749
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50895}
This file is no longer used by our Node.js branch, as it
has been updated to use gypfiles/v8.gyp.
R=machenbach@chromium.org
Bug: v8:7335
Change-Id: I6fe67b0839f2d7f4e2ec2df70f6cd88f25af7d92
Reviewed-on: https://chromium-review.googlesource.com/888745
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50891}
Do not overwrite handle values in AddNamedProperty which could cause
invalid handles in combination with CanonicalHandleScope.
Bug: chromium:802333
Change-Id: I373ab60579901bba65336ae3814e466e07392e22
Reviewed-on: https://chromium-review.googlesource.com/873032
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50890}
After deprecating the top-file Makefile, "make tags" cannot easily be
used any more. Moving the tags-related rules out to a separate Makefile
allows to continue using it using either "make -f tools/Makefile.tags
tags", or including it in your own Makefile.
R=yangguo@chromium.orgCC=ahaas@chromium.org
Bug: v8:7346
Change-Id: Id2a8186c392fbca4d144b166d598c9e930defa37
Reviewed-on: https://chromium-review.googlesource.com/881018
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50889}
With the new builtin optimization guard we can just speculatively assume
that the index passed to String#charAt and String#charCodeAt (in
optimized
code) is going to be within the valid range for the receiver. This is
what Crankshaft used to do, and it avoids Smi checks on the result for
String#charCodeAt, since it can no longer return NaN.
This gives rise to further optimizations of these builtins (i.e. to
completely avoid the tagging of char codes), and by itself already
improves the regression test originally reported from 650ms to
610ms.
Bug: v8:7127, v8:7326
Change-Id: I6c160540a1e002a37e44fa7f920e5e8f8c2c4210
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/873382
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50888}
This fixes %StringIteratorPrototype%.next to not mixup
UTF16 and UTF32, and consistently use UTF32 for now.
Bug: chromium:805855
Change-Id: If58e2fe0d9bebd894e12abf8af82881c74388294
Reviewed-on: https://chromium-review.googlesource.com/888741
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50886}
