- 19 Jun, 2017 7 commits
-
-
jarin authored
Toon suggested this as a mitigation to the problem of prototype fast mode switching invalidating prototype chain validity cell, and thus sending keyed store ICs to megamorphic state. BUG=chromium:723479 Review-Url: https://codereview.chromium.org/2943313002 Cr-Commit-Position: refs/heads/master@{#45993}
-
hpayer authored
This CL also reduces the minimum semi-space size to 512K. BUG=chromium:716032 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng Review-Url: https://codereview.chromium.org/2942543002 Cr-Commit-Position: refs/heads/master@{#45992}
-
Michael Starzinger authored
This removes both {BailoutId} as well as {TypeFeedbackId} numbers from almost all AST nodes. The only exception are {IterationStatement} nodes which still require an ID for on-stack replacement support. R=verwaest@chromium.org BUG=v8:6409 Change-Id: I5f7b7673ae5797b9cbc9741144d304f0d31d4446 Reviewed-on: https://chromium-review.googlesource.com/538792 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#45991}
-
Georg Neis authored
... in order to avoid creating an OsrHelper during code assembly, because its constructor accesses the heap. Bug: v8:6048 Change-Id: I3bf592a5a0f91752a9f5ec35982f962445512bb7 Reviewed-on: https://chromium-review.googlesource.com/530370 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45990}
-
bmeurer authored
We need to constant-fold JSHasInPrototypeChain nodes early during inlining, otherwise we already miss a couple of optimization opportunities if we wait until after typing. This moves the constant-folding part of the JSHasInPrototypeChain lowering back to JSNativeContextSpecialization, where it was before the changes in https://codereview.chromium.org/2934893002 (part of JSOrdinaryHasInstance lowering back then). BUG=v8:5269,v8:5989,v8:6483,chromium:733158 R=jgruber@chromium.org Review-Url: https://codereview.chromium.org/2943293002 Cr-Commit-Position: refs/heads/master@{#45989}
-
bmeurer authored
The heap verifier does certain invariant checks on JSBoundFunction objects, i.e. it assumes that the bound_target_function is a proper JSReceiver. The Deoptimizer cannot maintain this invariant, because it first allocates the JSBoundFunction in an invalid state and only afterwards fix up the state. But the GC (and thus the heap verifier) can observe this invalid state why materializing field values, so we need to relax the verification slightly. BUG=chromium:729573,chromium:732176 R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2933283002 Cr-Commit-Position: refs/heads/master@{#45988}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c6f78e9..bf51d56 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/59a182b..57e600c Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a248bd9..7659b77 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: Ifc9e2d8d7e1f2a1b223ffa3b20d55b1880eb88e7 Reviewed-on: https://chromium-review.googlesource.com/538261Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#45987}
-
- 17 Jun, 2017 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:5717 Change-Id: I6bed5f36b7d32cd893c4d1cb1bcc9f21b7fac2f1 Reviewed-on: https://chromium-review.googlesource.com/527932 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45986}
-
- 16 Jun, 2017 19 commits
-
-
Leszek Swirski authored
When iterating over stack frames in the cpu profiler, don't perform any object casts that have heap-testing DCHECKs. Instead, access values on the frame by offsets directly, and only check their tags for validity. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia54b18f8ab947c1827f17483806104f0d1d34136 Reviewed-on: https://chromium-review.googlesource.com/536973 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45985}
-
Toon Verwaest authored
Bug: Change-Id: I87b2c33dbf537aae949b25b2cd56fd20985e5980 Reviewed-on: https://chromium-review.googlesource.com/538659Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45984}
-
Toon Verwaest authored
This class contained a by-now unnecessary optimization of FindEntry. Since we always deal with internalized names by now anyway, there's no need to micro-optimize locally (it's a nop). Bug: Change-Id: I5a0046bcd23e2cb77c5902e850bac6211bd5518f Reviewed-on: https://chromium-review.googlesource.com/538581 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45983}
-
Mythri authored
The Smi versions of arithmetic bytecodes (AddSmi, SubSmi, MulSmi, DivSmi, ModSmi) have a fast path for Smi case and call to a builtin on the slow path. However, this builtin is only used by these bytecode handlers. This cl removes the builtins and inlines them into bytecode handlers. This will also save few checks in the slow-path. Subtract, multiply, divide and modulus also share the same checks to collect type feedback on several cases. This cl also refactors them to share the same code. Also removed a couple of TODOs that are no longer relevant. Bug: v8:4280, v8:6474 Change-Id: Id23bd61c2074564a1beacb0632165f52370ff226 Reviewed-on: https://chromium-review.googlesource.com/530845 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45982}
-
Camillo Bruni authored
With the introduction of the fast-cloning double fields in the CSA stub for literals we forgot to check for deprecated maps. As a result every subsequent IC-miss would have to migrate the objects from such boilerplates. This CL makes sure we don't use the deprecated map when copying boilerplates, thus restoring the original behavior. Bug: v8:6211 chromium:728682 Change-Id: If9ea1e0c5c6fb4236cb7a82ea33306a600925ac3 Reviewed-on: https://chromium-review.googlesource.com/538677Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45981}
-
Camillo Bruni authored
Change-Id: I224ea998eccf8fa18766b71962d487bb02768c78 Reviewed-on: https://chromium-review.googlesource.com/518146Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45980}
-
Camillo Bruni authored
Change-Id: If9debcecd714494e24adf895eb077d5ba51528d2 Reviewed-on: https://chromium-review.googlesource.com/535619 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#45979}
-
Michael Starzinger authored
R=jarin@chromium.org BUG=v8:6408 Change-Id: I1bc4f8f5ba37cf8a3632939356f56231ccc3226f Reviewed-on: https://chromium-review.googlesource.com/535458 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#45978}
-
Tobias Tebbi authored
Bug: chromium:733181 Change-Id: If5b0bc8592ba71962237814ad521499afda22edf Reviewed-on: https://chromium-review.googlesource.com/538653Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#45977}
-
Michael Lippautz authored
Remove dead code on the way. Bug: v8:6474 Change-Id: I7edb4277bc53ee92edf9523b943492782ec6efac Reviewed-on: https://chromium-review.googlesource.com/538652Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#45976}
-
Camillo Bruni authored
Storing the boilerplate on the first run leads to memory ovehead for code that is run only once. Hence we directly return the creating literal on the first run and only start creating copies from the second run on. Bug: v8:6211 Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad Reviewed-on: https://chromium-review.googlesource.com/530688 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#45975}
-
Mythri authored
Profiler ticks are reset when the type feedback changes for Load / Store ICs. This cl extends this to other operations as well. This allows us to tier up functions when the feedback vectors are stable. This is the first step for a set of follow up cls that will change the heuristics used in runtime-profiler. Bug: Change-Id: I875209712c6161e425a03475c14890a49155c0e1 Reviewed-on: https://chromium-review.googlesource.com/529165Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#45974}
-
jarin authored
This is in preparation for lowering monomorphic loads during graph building. This essentially moves the parts that will be shared to a separate class/file (proparty-access-builder.(cc|h)). I should say that we will not want to do accessor inlining during graph building because that would require us to create frame states (which is the thing we would like to avoid doing). Review-Url: https://codereview.chromium.org/2936673005 Cr-Commit-Position: refs/heads/master@{#45973}
-
Michael Starzinger authored
This removes the heuristic from {JSStackFrame::IsConstructor} that tried to infer whether a frame was called as a constructor or not from the receiver value. We are now carrying along the appropriate bit derived from the frame type instead. R=jgruber@chromium.org TEST=message/regress/regress-5727 BUG=v8:5727 Change-Id: I0e2f1d0f95485c84c4ebcd3cbfe0123c6afd2e01 Reviewed-on: https://chromium-review.googlesource.com/500313 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45972}
-
Ulan Degenbaev authored
This patch makes the SlotSet bucket type non-atomic by default and explicitly converts buckets to Atomic32/AtomicWord for each operation. Change-Id: Ifaa60a53eb68ca579185be23e379995aeeabe343 Reviewed-on: https://chromium-review.googlesource.com/535481 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#45971}
-
Michael Lippautz authored
Affects the Windows case where we over reserve for alignment reasons but actually already get aligned memory. Implemented on allocator level to potentially cover other platforms as well. Bug: Change-Id: I4859451f157e1e363db27413a43345fdd1990a06 Reviewed-on: https://chromium-review.googlesource.com/535454 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45970}
-
Camillo Bruni authored
Change-Id: Ia209def2faef1f765f74dc153fd8b4800c25be17 Reviewed-on: https://chromium-review.googlesource.com/521063 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#45969}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3ab6155..c6f78e9 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/b53a03d..ee9c3a7 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b7068ad..a248bd9 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: I3b501ec3151ba17a417a6e0876437b49e6a8435a Reviewed-on: https://chromium-review.googlesource.com/538234Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#45968}
-
gdeepti authored
BUG=v8:6478, chromium:729768 R=bradnelson@chromium.org, eholk@chromium.org Review-Url: https://codereview.chromium.org/2903153002 Cr-Original-Commit-Position: refs/heads/master@{#45931} Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d Review-Url: https://codereview.chromium.org/2903153002 Cr-Commit-Position: refs/heads/master@{#45967}
-
- 15 Jun, 2017 9 commits
-
-
Adam Klein authored
This reverts commit 8196e102. Reason for revert: Performance regression due to hashcode lookup. Original change's description: > [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins > > 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/531670 > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Commit-Queue: Adam Klein <adamk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45924} TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org Bug: v8:6354, chromium:733238 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia5a741b9587886298f3ca057f6a6adeba556b8e0 Reviewed-on: https://chromium-review.googlesource.com/537207Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#45966}
-
Sathya Gunasekaran authored
Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
-
Adam Klein authored
The Atomics object is a normal object, just like Math, JSON, etc., so we should be able to set it up in the same way those are set up since cff5470a. Change-Id: I46a9ba990707c0659f1a62f628b2c69204e536f8 Reviewed-on: https://chromium-review.googlesource.com/537076Reviewed-by: Ben Smith <binji@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#45964}
-
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: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#45962}
-
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: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45959}
-
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 4 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: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45954}
-