- 15 Jun, 2017 6 commits
-
-
Adam Klein authored
Before this patch, those builtin objects all used a strange-looking pattern for creation that involved creating a new constructor function (likely in order to get their ES5 [[Class]] set appropriately). But in modern times, with @@toStringTag as the mechanism of returning the correct toString value, there should be no need for those extra hoops, so simply use the Object constructor instead. Change-Id: Id841dace26bf71f73ec25a71f1297d502438b27c Reviewed-on: https://chromium-review.googlesource.com/533922 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45963}
-
Adam Klein authored
Change-Id: Ie4d21d2fc10db40efb42d66c9438ce3f3f01ce79 Reviewed-on: https://chromium-review.googlesource.com/533804Reviewed-by:
-
Georg Neis authored
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/535620Reviewed-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}
-
Leszek Swirski authored
This reverts commit b7a036a6. Reason for revert: We don't want to ever access the heap when walking the stack Original change's description: > [frames] Make interpreted frame detection stricter (reland) > > When iterating over stack frames, make the interpreted frame detection > require that the frame header contains the bytecode array. > > Currently, the stack frame iterator supports bytecode handlers that > don't create stack frames by checking if the top of the stack (i.e. the > return address) is the interpreter entry trampoline. However, optimized > code tail called from the interpreter entry trampoline can move the > stack pointer without clearing the stack, which means it can end up with > a pointer into the interpreter entry trampoline on the top of its stack > (in an uninitialized value), and be interpreted as an interpreted frame. > > To avoid such optimized code frames being interpreted as interpreted > frames, we now additionally test the frame header, to see if it contains > a valid pointer to a BytecodeArray. > > Reland of https://chromium-review.googlesource.com/c/535646/ > > Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a > Reviewed-on: https://chromium-review.googlesource.com/536935 > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45959} TBR=kozyatinskiy@chromium.org,leszeks@chromium.org Change-Id: I52a62c8e11af4d1565af92f10113b955f8c2c2f2 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/536938Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45960}
-
Leszek Swirski authored
When iterating over stack frames, make the interpreted frame detection require that the frame header contains the bytecode array. Currently, the stack frame iterator supports bytecode handlers that don't create stack frames by checking if the top of the stack (i.e. the return address) is the interpreter entry trampoline. However, optimized code tail called from the interpreter entry trampoline can move the stack pointer without clearing the stack, which means it can end up with a pointer into the interpreter entry trampoline on the top of its stack (in an uninitialized value), and be interpreted as an interpreted frame. To avoid such optimized code frames being interpreted as interpreted frames, we now additionally test the frame header, to see if it contains a valid pointer to a BytecodeArray. Reland of https://chromium-review.googlesource.com/c/535646/ Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a Reviewed-on: https://chromium-review.googlesource.com/536935Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4280b28..3ab6155 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/597f96e..59a182b TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: Idaf4f74956b999fe846a21efb85850e50e619bbb Reviewed-on: https://chromium-review.googlesource.com/536514Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#45958}
-
- 14 Jun, 2017 27 commits
-
-
jshin authored
Use ICU to check ID_Start, ID_Continue and WhiteSpace even for BMP when V8_INTL_SUPPORT is on (which is default). Change LineTerminator::Is() to check 4 code points from ES#sec-line-terminators instead of using tables and Lookup function. Remove Lowercase::Is(). It's not used anywhere. Update webkit/{ToNumber,parseFloat}.js to have the correct expectation for U+180E and the corresponding expected files. This is a follow-up to an earlier change ( https://codereview.chromium.org/2720953003 ). CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng BUG=v8:5370,v8:5155 TEST=unittests --gtest_filter=CharP* TEST=webkit: ToNumber, parseFloat TEST=test262: built-ins/Number/S9.3*, built-ins/parse{Int,Float}/S15* TEST=test262: language/white-space/mong* TEST=test262: built-ins/String/prototype/trim/u180e TEST=mjsunit: whitespaces Review-Url: https://codereview.chromium.org/2331303002 Cr-Commit-Position: refs/heads/master@{#45957} -
Jaideep Bajwa authored
Port bd3d091d Original Commit Message: With concurrent marking the write barrier should trigger even if the object is black because the concurrent marker could have fetched object field before marking the object black. R=ulan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:694255 LOG=N Change-Id: I3e3b5b467ab3c2eca45ac8d85523c8af4f5f5d4b Reviewed-on: https://chromium-review.googlesource.com/535736Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#45956}
-
Ulan Degenbaev authored
This patch also changes the visitor of BytecodeArray to use BytecodeArray::BodyDescriptor. BUG=chromium:733159 Change-Id: I2ac72c97ec51996b5b100c447b543895180f4f78 Reviewed-on: https://chromium-review.googlesource.com/535674Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45955}
-
Leszek Swirski authored
This reverts commit f577b2bb. Reason for revert: Failure on https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20verify%20csa/builds/1978 Original change's description: > [frames] Make interpreted frame detection stricter > > When iterating over stack frames, make the interpreted frame detection > require that the frame header contains the bytecode array. > > Currently, the stack frame iterator supports bytecode handlers that > don't create stack frames by checking if the top of the stack (i.e. the > return address) is the interpreter entry trampoline. However, optimized > code tail called from the interpreter entry trampoline can move the > stack pointer without clearing the stack, which means it can end up with > a pointer into the interpreter entry trampoline on the top of its stack > (in an uninitialized value), and be interpreted as an interpreted frame. > > To avoid such optimized code frames being interpreted as interpreted > frames, we now additionally test the frame header, to see if it contains > a BytecodeArray. > > Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70 > Reviewed-on: https://chromium-review.googlesource.com/535646 > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45951} TBR=kozyatinskiy@chromium.org,leszeks@chromium.org Change-Id: Icc009cf97b816f6c33574782ed9ab473387886c9 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/535478Reviewed-by:
-
Toon Verwaest authored
Bug: chromiume:733118 Change-Id: Ic144342d86fc84bf5c4700cec357ac8f3c6b2cb3 Reviewed-on: https://chromium-review.googlesource.com/535522Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45953}
-
Michael Lippautz authored
Bug: chromium:733059, chromium:724947 Change-Id: Id7abc22ee0975cd609cc06a02552f68e9e0077e8 Reviewed-on: https://chromium-review.googlesource.com/535596 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Leszek Swirski authored
When iterating over stack frames, make the interpreted frame detection require that the frame header contains the bytecode array. Currently, the stack frame iterator supports bytecode handlers that don't create stack frames by checking if the top of the stack (i.e. the return address) is the interpreter entry trampoline. However, optimized code tail called from the interpreter entry trampoline can move the stack pointer without clearing the stack, which means it can end up with a pointer into the interpreter entry trampoline on the top of its stack (in an uninitialized value), and be interpreted as an interpreted frame. To avoid such optimized code frames being interpreted as interpreted frames, we now additionally test the frame header, to see if it contains a BytecodeArray. Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70 Reviewed-on: https://chromium-review.googlesource.com/535646Reviewed-by:
-
Alexey Kozyatinskiy authored
Context::Lookup method should support Module variables. Bug: chromium:717670 Change-Id: I58d3448b9048c7f9dd7ab8b720803b3503cf91ae Reviewed-on: https://chromium-review.googlesource.com/519389 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
-
Pierre Langlois authored
This cleanup is the result of trying to modify the `Assembler::addrmod1` method and realising it's very easy to break it. It handles three groups of instructions with different operands and uses `r0` when a register is not used: - General case: rd, rn, (rm|rm shift #imm|rm shift rs) - Comparison instructions: rn, (rm|rm shift #imm|rm shift rs) - Move instructions rd, (rm|rm shift #imm|rm shift rs) Let's use `no_reg` instead of `r0` with explicit checks and assertions so that it's clear this method is used with multiple types of instructions. Additionaly, keep the order of operands as "rd", "rn", "rm". As drive-by fixes, I've taken the opportunity to add a few helper methods to the `Operand` class. Bug: Change-Id: If8140d804bc90dea1d3c186b3cee54297f91462a Reviewed-on: https://chromium-review.googlesource.com/531284 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#45949}
-
georgia.kouveli authored
BUG= Review-Url: https://codereview.chromium.org/2922983002 Cr-Commit-Position: refs/heads/master@{#45948}
-
jgruber authored
Until now, ATOM regexps (i.e. simple patterns don't require regexp matching logic but can use generic string matching algorithms instead) have always gone through the slow runtime. This CL implements a fast path in CSA which simply calls StringIndexOf internally and then sets up the last-match-info as required. Local microbenchmarks show a 30% improvement for RE.p.exec on ATOM regexps, and a 5% improvement on Octane/RegExp. Bug: v8:6462 Change-Id: I35b4c5caf416fa35fe388dd58e34dea55b098d09 Reviewed-on: https://chromium-review.googlesource.com/535455 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Caitlin Potter authored
Simplifies the implementation of IteratorClose in IteratorBuiltinsAssembler, and makes clear that it is only invoked when an exception occurs. Adds exception handling support to GetIterator, IteratorStep, and IteratorCloseOnException. Moves the Promise.all resolveElement closure and it's caller to builtins-promise-gen.cc. Instead of creating an internal array (and copying its elements into a result array), a single JSArray is allocated, and appended with BuildAppendJSArray(), falling back to %CreateDataProperty(), and elements are updated in the resolve closure the same way. This should always be unobservable. This CL increases the size of snapshot_blob.bin on an x64.release build by 8.51kb BUG=v8:5343 R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org, hpayer@chromium.org, tebbi@chromium.org Change-Id: I29c4a529154ef49ad65555ce6ddc2c5b7c9de6b3 Reviewed-on: https://chromium-review.googlesource.com/508473 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
jarin authored
Review-Url: https://codereview.chromium.org/2937943002 Cr-Commit-Position: refs/heads/master@{#45945}
-
Jakob Kummerow authored
Bug: v8:6474 Change-Id: I24d067ac77c2cb557d0b3f6e2c8c512761c160f1 Reviewed-on: https://chromium-review.googlesource.com/531384 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#45944}
-
Michael Starzinger authored
This removes support for reconstructing stack frames for full-codegen from the deoptimizer. We no longer deoptimize to such code. This also allows us to remove the {DeoptimizationOutputData} data structure. R=jarin@chromium.org BUG=v8:6409 Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d Reviewed-on: https://chromium-review.googlesource.com/535537Reviewed-by: -
Marja Hölttä authored
These were too aggressively de-inlined as part of https://chromium-review.googlesource.com/c/528102 . BUG=chromium:733161 Change-Id: I88e9f969dcd6142cbbbb2662edd8108ad687c522 Reviewed-on: https://chromium-review.googlesource.com/535640Reviewed-by:
-
Michael Achenbach authored
NOTRY=true NOTREECHECKS=true TBR=vogelheim@chromium.org Bug: chromium:726584 Change-Id: I7a20b8897e6db681acec76c135e4d17674e17729 Reviewed-on: https://chromium-review.googlesource.com/535517 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#45941}
-
Ulan Degenbaev authored
BUG=chromium:694255 TBR=mlippautz@chromium.org Change-Id: I5c6fbb392d68a348e3a8b3fb52368232883e9931 Reviewed-on: https://chromium-review.googlesource.com/535594Reviewed-by:
-
Michael Starzinger authored
This removes the ability to prepare bailout points in code generated by the {FullCodeGenerator}. Such code is no longer used as the target of deoptimization attempts, hence storing deoptimization data is obsolete. R=jarin@chromium.org BUG=v8:6409 Change-Id: I3200182a6e88014ce953881fa0d1ac0bc65ee424 Reviewed-on: https://chromium-review.googlesource.com/533153Reviewed-by: -
Ulan Degenbaev authored
With concurrent marking the write barrier should trigger even if the object is black because the concurrent marker could have fetched object field before marking the object black. BUG=chromium:694255 Change-Id: Icacc5672defeec85936e37d7d06780c74b97732c Reviewed-on: https://chromium-review.googlesource.com/533614Reviewed-by:
-
Michael Lippautz authored
TBR=ulan@chromium.org NOTRY=true Bug: chromium:694255 Change-Id: I430fad8916112141eec60914d73640b31d3da9d4 Reviewed-on: https://chromium-review.googlesource.com/535555Reviewed-by:
-
Michael Starzinger authored
R=machenbach@chromium.org BUG=v8:6408 Change-Id: I3c785acd30d8feb0541e9acdf0c44225a01cb71c Reviewed-on: https://chromium-review.googlesource.com/533154Reviewed-by:
-
Camillo Bruni authored
For unknown Argument object Maps we have to expect that constants fields are kept on the Map. Bug: chromium:729597 Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30 Reviewed-on: https://chromium-review.googlesource.com/532900Reviewed-by:
-
jgruber authored
This completes refactoring started in 0a355777. Bug: v8:6474 Change-Id: Ia2ea66e10e4f1d55551fe145f67f4021ae254b23 Reviewed-on: https://chromium-review.googlesource.com/532997 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#45934}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/05cc70d..4280b28 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/e6b02f2..597f96e Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fbd95a5..b7068ad TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: I338f86ce6466baded9fcbaea5ed0c00739a661b3 Reviewed-on: https://chromium-review.googlesource.com/535313Reviewed-by:
-
machenbach authored
Revert of [wasm] Increase WebAssembly.Memory maximum size to ~2GB (patchset #10 id:200001 of https://codereview.chromium.org/2903153002/ ) Reason for revert: gc stress failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/11122 Original issue's description: > [wasm] Increase WebAssembly.Memory maximum size to 2GB > > BUG=v8:6478, chromium:729768 > > R=bradnelson@chromium.org, eholk@chromium.org > > Review-Url: https://codereview.chromium.org/2903153002 > Cr-Commit-Position: refs/heads/master@{#45931} > Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d TBR=bradnelson@chromium.org,eholk@chromium.org,gdeepti@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6478, chromium:729768 Review-Url: https://codereview.chromium.org/2935243002 Cr-Commit-Position: refs/heads/master@{#45932}
-
gdeepti authored
BUG=v8:6478, chromium:729768 R=bradnelson@chromium.org, eholk@chromium.org Review-Url: https://codereview.chromium.org/2903153002 Cr-Commit-Position: refs/heads/master@{#45931}
-
- 13 Jun, 2017 7 commits
-
-
Ben Smith authored
It is only attached to the global object if the --harmony-sharedarraybuffer flag is enabled, but this allows more objects to be added to the snapshot which seems to reduce the amount of heap memory used per context. Bug: chromium:724053 Change-Id: I5d1115a0e3ed9abf41cb3ab80d19d622cbef7b93 Reviewed-on: https://chromium-review.googlesource.com/534594Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#45930}
-
bbudge authored
- Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed by S8x16Shuffle. This aligns us with the latest WASM SIMD spec. LOG=N BUG=v8:6020 Review-Url: https://codereview.chromium.org/2923103003 Cr-Commit-Position: refs/heads/master@{#45929}
-
bbudge authored
LOG=N BUG=v8:6020 Review-Url: https://codereview.chromium.org/2928853002 Cr-Commit-Position: refs/heads/master@{#45928}
-
bmeurer authored
Builtins::kReturnReceiver is used for the Symbol.iterator function on iterators, and just returns the iterator itself. For example, for-of or yield* with a generator will first call generator[Symbol.iterator](), which simply returns the generator itself. Inlining this particular builtin into TurboFan is trivial and avoids that call completely, enabling more possibilities for LoadElimination and EscapeAnalysis to get rid of even more checks in common generator code. BUG=v8:6344,v8:6351,v8:6354 R=jgruber@chromium.org Review-Url: https://codereview.chromium.org/2938683002 Cr-Commit-Position: refs/heads/master@{#45927}
-
Ulan Degenbaev authored
Change-Id: Ie79607b16270a50ef74261ee8e34a3f1321454c1 Reviewed-on: https://chromium-review.googlesource.com/534233Reviewed-by:
-
bmeurer authored
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}
-
Adam Klein authored
They were already implemented mostly in C++ (only error/negative cases were handled in script), so this is mostly just a cleanup. Only the constructors remain in script after this CL. Bug: v8:6354 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb Reviewed-on: https://chromium-review.googlesource.com/531670Reviewed-by:
-
