- 28 Nov, 2018 16 commits
-
-
George Wort authored
This reduces wasm's ABI on Arm to only using the even-numbered float registers in anticipation of Liftoff supporting f32 values on the arm32 port. This is due to Liftoff assuming a one-to-one mapping between double and float registers. The ABI must be restricted in order to allow Liftoff compiled and Turbofan compiled functions to call each other. Turbofan continues to use all float registers internally however. Bug: v8:6600 Change-Id: I47d91b8216136e57f42fd9665ed57ec631eb0374 Reviewed-on: https://chromium-review.googlesource.com/c/1352278Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57901}
-
Andreas Haas authored
This new spec test version is https://github.com/WebAssembly/spec/pull/922 now. R=titzer@chromium.org Change-Id: I4e88e6fb5d20e0ab1d4c1011db88171937c0ff86 Reviewed-on: https://chromium-review.googlesource.com/c/1352300Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57900}
-
Maya Lekova authored
This reverts commit d5f4a33e. Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967 Original change's description: > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame > > Before fast C calls, store the current FP and PC on the isolate. When > iterating frames in SafeStackFrameIterator, check if these fields are > set and start iterating at the calling frame's FP instead of the current > FP, which will be in C++ code. We need to do this because c_entry_fp is > not set on the Isolate for Fast-C-Calls because we don't build an exit > frame. > > This change makes stack samples that occur within 'Fast-C-Calls' > iterable, meaning we can properly attribute ticks within the JS caller. > > Fast-C-Calls can't call back into JS code, so we can only ever have one > such call on the stack at a time, allowing us to store the FP on the > isolate rather than the stack. > > TBR=v8-mips-ports@googlegroups.com > > Bug: v8:8464, v8:7202 > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 > Reviewed-on: https://chromium-review.googlesource.com/c/1340241 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> > Reviewed-by: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57896} TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8464, v8:7202 Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#57899}
-
Jacob Bramley authored
The test was flaky because it assumed that AllocatedAssemblerBuffer would eventually return an address within near-call range. Rarely, this did not happen (within the retry limit), and so the test would crash. This fix allocates a single, kMaxWasmCodeMemory-sized buffer for the test, and generates call sequences within that buffer. BUG=v8:8245 Change-Id: I4b44d897c6cbda15a18ab992fa57805de3b2db29 Reviewed-on: https://chromium-review.googlesource.com/c/1347484Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jacob Bramley <jacob.bramley@arm.com> Cr-Commit-Position: refs/heads/master@{#57898}
-
Toon Verwaest authored
Change-Id: Iadc3d916dcda6f03c467e77fedff6d315dbb67f6 Reviewed-on: https://chromium-review.googlesource.com/c/1352299Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57897}
-
Peter Marshall authored
Before fast C calls, store the current FP and PC on the isolate. When iterating frames in SafeStackFrameIterator, check if these fields are set and start iterating at the calling frame's FP instead of the current FP, which will be in C++ code. We need to do this because c_entry_fp is not set on the Isolate for Fast-C-Calls because we don't build an exit frame. This change makes stack samples that occur within 'Fast-C-Calls' iterable, meaning we can properly attribute ticks within the JS caller. Fast-C-Calls can't call back into JS code, so we can only ever have one such call on the stack at a time, allowing us to store the FP on the isolate rather than the stack. TBR=v8-mips-ports@googlegroups.com Bug: v8:8464, v8:7202 Change-Id: I7bf39eba779dad34754d5759d741c421b362a406 Reviewed-on: https://chromium-review.googlesource.com/c/1340241 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#57896}
-
Dan Elphick authored
Bug: v8:7295, v8:8238 Change-Id: Ide105b69ee77707a5a28d16abfb1ab44ebc3995d Reviewed-on: https://chromium-review.googlesource.com/c/1352273Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#57895}
-
Marja Hölttä authored
BUG=v8:7490,v8:8238 Change-Id: Id55ad482903abac635981d9e417e255fec427c52 Reviewed-on: https://chromium-review.googlesource.com/c/1352285Reviewed-by:
-
Jakob Kummerow authored
pending a better approach. Bug: v8:8516 Change-Id: Ic107184b46c85ae5724619cc82c99686aee7edb9 Reviewed-on: https://chromium-review.googlesource.com/c/1352794Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57893}
-
Toon Verwaest authored
Bug: chromium:908975 Change-Id: I3dd9cf32de5b11554c2e1cbc0538c9b11ecda09d Reviewed-on: https://chromium-review.googlesource.com/c/1352286Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57892}
-
tzik authored
MicrotaskQueue didn't free its buffer on GC phase if it's empty. Bug: v8:8124 Change-Id: Icdd6a67873cab164dcf67ed1caf5cca55e3f7954 Reviewed-on: https://chromium-review.googlesource.com/c/1351856Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Cr-Commit-Position: refs/heads/master@{#57891}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/076d347..bbd67a3 Rolling v8/test/wasm-js/data: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/e822213..3dc2dc2 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6c18a1a..44d4b29 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7fa2bdf..8a671fe Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/b6e9e23..157bec8 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I1ca88060fc4d1f9ca46ca68ba295f76fd50926f8 Reviewed-on: https://chromium-review.googlesource.com/c/1352793Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#57890}
-
Ben Smith authored
The MemoryInitImmediate and TableInitImmediate read a Memory/Table index, followed by a segment index. If reading the first index fails, we need to stop reading, or the decoder will read past the end. Bug: chromium:907324 Change-Id: I3eb46c08d03e3b2e44ed4081d307b32c799abcec Reviewed-on: https://chromium-review.googlesource.com/c/1351502 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This reverts commit d37f6fd6. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20gc%20stress/19643 Original change's description: > [Intl] Handle invalid values in locale > > Fix the bug that we call setKeywordValue w/o convert the key to legacy key. > > Bug: v8:7481 > Change-Id: I5a743e41d02b64385c5050fc1d83279741e24659 > Reviewed-on: https://chromium-review.googlesource.com/c/1339243 > Commit-Queue: Frank Tang <ftang@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Jungshik Shin <jshin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57886} TBR=jshin@chromium.org,gsathya@chromium.org,ftang@chromium.org Change-Id: I3765eed7a9bdf123321c6d0589dfb72ab8ae2b2f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7481 Reviewed-on: https://chromium-review.googlesource.com/c/1352284Reviewed-by:
-
Aseem Garg authored
waiting_ flag is now set inside a lock to prevent data race. This means that waiting_ is false when callback is called at start of wait. To deal with the new behavior, NotifyWake now always tries to Notify and sets interrupted_ flag which will be handled by any future wait. R=binji@chromium.org BUG=v8:8497 Change-Id: Ia4fd39bcf18875d9be21bafc176ab562b083e68b Reviewed-on: https://chromium-review.googlesource.com/c/1351237 Commit-Queue: Aseem Garg <aseemgarg@chromium.org> Reviewed-by:
Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#57887}
-
Frank Tang authored
Fix the bug that we call setKeywordValue w/o convert the key to legacy key. Bug: v8:7481 Change-Id: I5a743e41d02b64385c5050fc1d83279741e24659 Reviewed-on: https://chromium-review.googlesource.com/c/1339243 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Jungshik Shin <jshin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57886}
-
- 27 Nov, 2018 24 commits
-
-
Sven Sauleau authored
See usage in the js-api tests; previously it would have thrown without executing any tests. Now, it can be used to generate trapping functions. Bug: v8:8319 Change-Id: Ia1643d8f337a10ea86c1e700c7702ed7d3ed0c97 Reviewed-on: https://chromium-review.googlesource.com/c/1352298Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#57885}
-
Jakob Kummerow authored
to the new design. Bug: v8:3770 Change-Id: Ic77a4f645a1ca3ed9be87690155e988723132471 Reviewed-on: https://chromium-review.googlesource.com/c/1350285Reviewed-by:
-
Igor Sheludko authored
which are no longer derived from FixedArray and therefore IsFixedArray() check no longer includes Contexts. Bug: chromium:908877 Change-Id: I3aed0d38f5b1c00c9e27b7d5b6d29cdd5666ba86 Reviewed-on: https://chromium-review.googlesource.com/c/1352280Reviewed-by:
-
Hannes Payer authored
Bug: chromium:852420 Change-Id: I12cac5981cbb2af1c1bd150bfb5fcec028e8876d Reviewed-on: https://chromium-review.googlesource.com/c/1352297Reviewed-by:
-
Toon Verwaest authored
That reduces the overhead of ParseAssignmentExpression at the cost of a few more branches in the possible arrow head paths. This also fixes the case where an outer scope of an arrow function didn't call eval but a parameter initializer does. Previously the outer scope was also marked as calling eval, causing worse performance. (Unlikely to happen though.) Change-Id: I5263ef342f14e97372f5037fa659f32ec2ad6d34 Reviewed-on: https://chromium-review.googlesource.com/c/1352275 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57881}
-
Hannes Payer authored
Bug: chromium:852420 Change-Id: Ie3c2bb4d1d329e84e2cb9431cca129bdd7d09271 Reviewed-on: https://chromium-review.googlesource.com/c/1352291 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Caitlin Potter authored
This avoids leaving the heap in an invalid state if a GC occurs during population of the cloned property array, as is done in other IC builtins. BUG=chromium:904167, v8:7611 R=jkummerow@chromium.org, ishell@chromium.org Change-Id: I0350ed2d65b72e299f7109b7d5aa86331f60e940 Reviewed-on: https://chromium-review.googlesource.com/c/1350282 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57879}
-
Igor Sheludko authored
This CL introduces Tagged_t and AtomicTagged_t typedefs which represent the storage type of tagged values in V8 heap. Bug: v8:7703 Change-Id: Ib57e85ea073eaf896b6406cf0f62adcef9a114ce Reviewed-on: https://chromium-review.googlesource.com/c/1352294Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57878}
-
Igor Sheludko authored
Bug: v8:8238 Change-Id: I7fa1538909bfaf368498ebcc1c59eed258e81a16 Reviewed-on: https://chromium-review.googlesource.com/c/1352272Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57877}
-
Joyee Cheung authored
This patch refactors the parsing of object literal properties and class literal properties, putting the out parameters into a pointer of struct `ParsePropertyInfo`. This struct is also aware of its potition so `ParsePropertyName()` can also use this information to error when parsing a private name in an object literal. It also makes sure that the `ClassLiteralProperty::Kind` are all inferred from the `ParsePropertyKind` and get used right away instead of being passed around as out parameters. Bug: v8:8330 Change-Id: I4c52592dfcaa3c8df30c4aba4c46e5c675acb394 Reviewed-on: https://chromium-review.googlesource.com/c/1347904 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
-
Ross McIlroy authored
When restarting a frame on returning from a debug break, we are going to drop the current function frame, therefore the return value and next bytecode are not going to be used. Special case these situations since with bytecode flushing it is possible the SFI for the executing function might have been flushed (if edited by liveedit) which causes failures when trying to read from the bytecode array. BUG=v8:8395 Change-Id: I18adaa5d91c244e6d13e8703ed41c300f793681d Reviewed-on: https://chromium-review.googlesource.com/c/1352270 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Camillo Bruni authored
Only log incrementally deserialized maps with --trace-maps instead of iterating the whole heap and print all existing maps on every partial deserialization for new contexts. This should greatly improve performance of --trace-maps on websites with many iframes. - Add helpers to share code: LogNewObjectEvents, LogScriptEvents, LogNewMapEvents - Link AllocationSites before any GC Change-Id: I5322421a83e057518f871540691511c80bc7786a Reviewed-on: https://chromium-review.googlesource.com/c/1342029Reviewed-by:
-
Sigurd Schneider authored
This CL fixes some style issues and improves json output for the LoC counting script tools/locs.py. Notry: true Change-Id: I0805904e44ab240945ef88dd8214abb8ae02cf7d Reviewed-on: https://chromium-review.googlesource.com/c/1352271 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Unfortunately the previous strategy was slower but more memory efficient. For now simply revert. Revert "[zone] Use 32kb instead of 1MB as high zone page size" Revert "[zone] Get rid of the Zone's segment pool" Revert "[zone] Further simplify zone expansion, use single default page size" Bug: chromium:908359 Change-Id: I649542e7e61eef0c14a26ffd21039e8340ab4d04 Reviewed-on: https://chromium-review.googlesource.com/c/1351027Reviewed-by:
-
Igor Sheludko authored
This CL fixes allocation size alignment violation when allocating store buffer. If the actual CommitPageSize happens to be bigger than kMinExpectedOSPageSize we will have a bit of memory wastage but that's a fair trade-off for having fast store buffer overflow check in write barriers. Change-Id: I1d775aa8b203cb198e8332477b0bc2befcd9b006 Reviewed-on: https://chromium-review.googlesource.com/c/1351007 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
tzik authored
A pointer to MicrotaskQueue is stored in a NativeContext field as a Smi, that is discouraged. This CL replaces it to use the dedicated field. Bug: v8:8124 Change-Id: I5a770624b3a9c922051e86243da2ae216aaacf3a Reviewed-on: https://chromium-review.googlesource.com/c/1351855 Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This unifies the order of i-cache flushing and permission changing throughout V8. According to cctest/test-icache flushing after the permission change is not robust on some ARM32 and ARM64 devices. There have been observed failures of {TestFlushICacheOfExecutable} on some devices. So far there haven't been any observed failures of the corresponding {TestFlushICacheOfWritable} test. Also the order of flushing before the permission change is the natural order in which the GC currently performs operations. Until we see concrete data substantiating the opposite, the following is the supported and intended order throughout V8: exec -> perm(RW) -> patch -> flush -> perm(RX) -> exec This CL tries to establish said order throughout the codebase. R=ulan@chromium.org TEST=cctest/test-icache BUG=v8:8507,chromium:845877 Change-Id: Ic945082e643aa2d142d222a7913a99816aff4644 Reviewed-on: https://chromium-review.googlesource.com/c/1351025Reviewed-by: -
Toon Verwaest authored
Pushing unresolved variables at the front was an optimization for the case where we didn't have an end pointer. That forces us to do an O(<new elements>) walk to rescope variables. The implementation was more generic and even did O(<all elements>). Now that we have an end pointer we can simply push at the end and MoveTail which is O(1). Change-Id: I65cd5752b432223d95cd529452a064d8dcc812e1 Reviewed-on: https://chromium-review.googlesource.com/c/1351010 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Change-Id: I8704003f05e74d55e724d669f5bbcef5c2214bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1351018Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57867}
-
Camillo Bruni authored
Bug: chromium:907714 Change-Id: Ie8eacff1b12ec74faa392a1d2c8545f873ab13a1 Reviewed-on: https://chromium-review.googlesource.com/c/1351023Reviewed-by:
-
Yang Guo authored
This is an attempt to reland https://crrev.com/1d726111ab7087a5, that was reverted at https://crrev.com/0a820125230bec24. Tbr: bmeurer@chromium.org Bug: chromium:887920, v8:7253 Change-Id: I785417de7d0560b93bda5ade623fa5be3647d7dd Reviewed-on: https://chromium-review.googlesource.com/c/1350530 Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
This reverts commit fac6f63e. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=907479 Original change's description: > Use CopyElements (which uses memcpy) to copy FixedDoubleArray. > > This improves the performance of ExtractFixedArray and > CloneFastJSArray for double arrays, which in turn improve the > performance of cloning double arrays with slice() or spreading. > > This, however, does not improve performance of spreading holey > double arrays, because spreading needs extra work to convert > holes to undefined. > > Bug: v8:7980 > Change-Id: Ib8aed74abbb0b06982a3b754e134fa415cb7de2d > Reviewed-on: https://chromium-review.googlesource.com/c/1280308 > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#56680} TBR=mvstanton@chromium.org,neis@chromium.org,sigurds@chromium.org,dhai@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7980, chromium:907479 Change-Id: Iacf37fa3276345fe8e264fe976d296b015ed6790 Reviewed-on: https://chromium-review.googlesource.com/c/1351003Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#57864}
-
Dan Elphick authored
Moves ReturnValue::Set from V8_DEPRECATE_SOON to V8_DEPRECATED now that chromium no longer uses it. Bug: v8:7289, v8:8238 Change-Id: Ib705f62dcaa508a8b42a67ed7eaafe7860e3e848 Reviewed-on: https://chromium-review.googlesource.com/c/1351020Reviewed-by:
-
Ulan Degenbaev authored
Now the parser rejects dates outside the [-8640e12ms, 8640e12ms] range as specified by ES6 section 20.3.1.1. Bug: chromium:908248, v8:7781 Change-Id: I3391ce7398c971d54794e5011564a0527794667a Reviewed-on: https://chromium-review.googlesource.com/c/1350996 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
