- 12 Apr, 2019 10 commits
-
-
Frank Tang authored
Bug: v8:9081 Change-Id: I505e8ee4bf58f2da09962ae9a7056931435c10f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562587Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60806}
-
Simon Zünd authored
This reverts commit ffe6940f. Reason for revert: Breaks UBSan bot Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623 > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} TBR=sigurds@chromium.org,tebbi@chromium.org,szuend@chromium.org Change-Id: I30ccec8ac28158c102a4e9a01074432172685f96 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8880 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564207Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60805}
-
Simon Zünd authored
This is a reland of 251d1623 The reland fixes ASAN component builds by adding RTTI build config to both torque executables. Big thanks to sigurds for finding the fix. Original change's description: > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 3bd49f9b > > The issue on the windows bot is apparently a compiler bug in MSVC related to > move construction. The fix seems to be to change the order of the fields in > "JsonParseResult" (go figure). > > Drive-by-change: Fix LS on windows by emitting correct line endings and > enabling exceptions for the LS executable as well. > > Original change's description: > > [torque] Throw exception instead of aborting if something goes wrong > > > > This CL enables exceptions for the Torque compiler and Torque language > > server. Instead of aborting when something goes wrong during > > compilation, a TorqueError is thrown, containing the error message > > and a source position. The compiler executable still prints the error > > and aborts, while the language server will pass this information > > along to the client (not included in this CL). > > > > R=danno@chromium.org > > > > Bug: v8:8880 > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60512} > > Bug: v8:8880 > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60736} Bug: v8:8880 Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60804}
-
Simon Zünd authored
Adding a 'PrepareFunctionForOptimization' call will prevent the test case in question to become flaky when stress testing bytecode flushing. R=jarin@chromium.org Bug: v8:9123 Change-Id: If192ebf571d3cd4f0d1ee31bc3f6313b74d3c866 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564202 Auto-Submit: Simon Zünd <szuend@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60803}
-
Sergiy Belozorov authored
R=machenbach@chromium.org, tmrts@chromium.org Bug: v8:8969 Change-Id: I2e565b114383d085ea5c8dbcff45e3794d4f1f6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564201Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#60802}
-
Simon Zünd authored
This CL changes the Symbol "stack_trace_symbol" to directly hold a FrameArray instead of wrapping it with a JSArray first. Bug: v8:9115 Change-Id: I2ac0b1fb380211568abdc6d9f50431c405349dec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564060Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60801}
-
Clemens Hammacher authored
For synchronous compilation, the foreground thread takes part in compilation. It should only compile Liftoff functions though, otherwise it might unnecessarily delay initial compilation by executing expensive TurboFan units. Drive-by: Minor refactoring to avoid else after return. R=mstarzinger@chromium.org Bug: v8:8916 Change-Id: Ibf994a9a48417943652f13096419afd73cb59f85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564192 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60800}
-
Yu Yin authored
This fix build error(mksnapshot) on mips64el after https://crrev.com/c/1526009. We should implements "compress changes" functions on mips64, but now mips64 build failed while enable pointer compression, we need port some more pacth to mips64, for example: https://crrev.com/c/1477215 Change-Id: I745cc9b0cf60825f526720db7f5eaedd923b4634 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549133 Commit-Queue: Yu Yin <xwafish@gmail.com> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60799}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ba0d0b9..f10a653 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/dc0c991..095babf Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6379cd3..1de3cd4 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I9b60cb689ab8df25f3bed920e33eca29610ca990 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565486Reviewed-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@{#60798}
-
Frank Tang authored
1. Add Intl::NumberFieldToType to support RelativeTimeFormat by refactoring IcuNumberFieldIdToNumberType 2. Use formatNumericToValue / formatToValue to implement formatToParts Bug: v8:8837 Change-Id: I4d8fab9c337ec02eeb3500b4c0f90547e48444e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560661Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60797}
-
- 11 Apr, 2019 30 commits
-
-
Ben Smith authored
See intent to ship here: https://groups.google.com/forum/#!topic/v8-users/zM05lYEBVog wasm-module-builder.js is also changed to use the new syntax for specifying a table index in an element segment. In the MVP, the table index was always zero. The reference types proposal adds support for multiple tables, and originally used this value to specify a non-zero table index. The bulk memory proposal needed a way to specify a passive element segment, so it re-purposed the table index as a flags field and uses a different field for the table index. Bug: v8:7747 Change-Id: If24f2d04e88a29b714f1a78ed417803bae702c76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560215 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#60796}
-
Deepti Gandluri authored
Bug: chromium:925244 Change-Id: If9c00f85b1dece93057b541bf0fe1b0a05b81ceb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565032 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60795}
-
Jaroslav Sevcik authored
This is particularly useful to fuzzers that seek to provoke optimization. Bug: v8:9119 Change-Id: I729f72a0e22686fbd56793875175c230e0230823 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564196 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#60794}
-
Z Duong Nguyen-Huu authored
The last step in array.splice slow-path is to update length of the array https://cs.chromium.org/chromium/src/v8/src/builtins/array-splice.tq?rcl=59a29d88cc5972d2323a80a70de19ffd2812e5e4&l=349. For sealed object, it should be nop. Bug: chromium:951164 Change-Id: I0c3098526c7df6c4dd734dd6c79cc0bba3b9b213 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559217 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#60793}
-
Simon Zünd authored
This reverts commit 21adacab. Reason for revert: Breaks Mac64 GC Stress Bot Original change's description: > Reserve two in-object properties slots for JSErrors > > The most common use-case for creating errors is "new Error('message')". > The resulting JSError object has two properties. The message passed to > the constructor and an accessor for the stack. > > This CL reserves two in-object property slots for these two, so no > PropertyArray has to be created. > > Bug: v8:9116 > Change-Id: I84467453446f333bf65425807707ee6581894e61 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564195 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60791} TBR=jgruber@chromium.org,bmeurer@chromium.org,szuend@chromium.org Change-Id: I4667c4f49b3244d7809e8605b3858e246858a413 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9116 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564200Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60792}
-
Simon Zünd authored
The most common use-case for creating errors is "new Error('message')". The resulting JSError object has two properties. The message passed to the constructor and an accessor for the stack. This CL reserves two in-object property slots for these two, so no PropertyArray has to be created. Bug: v8:9116 Change-Id: I84467453446f333bf65425807707ee6581894e61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564195Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60791}
-
Clemens Hammacher authored
This unifies the logic used for foreground compilation and background compilation. The main thread used a separate {FetchAndExecuteCompilationUnit} function so far, which implements the same as the {BackgroundCompileTask}, but without compiling in batches. This CL removes that method, and uses the same {ExecuteCompilationUnits} method from both foreground and background tasks. R=mstarzinger@chromium.org Bug: v8:8916 Change-Id: Id30edb766c46d860a5b0ef45386af7e9fd6a1cc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564191Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60790}
-
Hannes Payer authored
This avoids accessing the page flags of all old generation PagedSpace pages when starting sweeping. Bug: v8:9093 Change-Id: Ibdfb35f3e368107f8c364c9498312b01edce47d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554688Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60789}
-
Frank Tang authored
Bug: v8:9110 Change-Id: I834ce91e8c77dc04fa261abb9bd415eb03bf949e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562732Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60788}
-
Frank Tang authored
https://chromium.googlesource.com/external/github.com/tc39/test262/+log/6119191..8e5ab69 Bug: v8:7834 Change-Id: I91401fd050a89a8d2d04c1b1ae21ceb7b595305e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562733Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60787}
-
Z Duong Nguyen-Huu authored
It should work when Object.defineProperty is used to set a new value for seal object. Add more test to cover this case as well. Bug: chromium:951374 Change-Id: Idbbcc052b627587c71d5b5252340130d0fdfd595 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562470Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60786}
-
Clemens Hammacher authored
Instead of a hack in the {AsyncCompileJob}, handle empty modules by just calling the callbacks for "baseline finished" and "top tier finished" immediately, at the point where compilation would be started usually. R=mstarzinger@chromium.org Bug: v8:8916 Change-Id: Id7b32fe2508e5a8902c60865f7f7d675a7a02610 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564054 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60785}
-
Toon Verwaest authored
Change-Id: I0618d37226c2a6b55d67d51ad24f95c0f582bb91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564197 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#60784}
-
Michael Lippautz authored
Exclude embedder tracing time Bug: chromium:945806 Change-Id: I9719a42f86fd6edad8fd2b0f707b4dc7feada277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564437Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#60783}
-
peterwmwong authored
Bug: v8:8976 Change-Id: Ic903d353f05d0c16d4b735bbb1307ff6403fa72e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559211Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Cr-Commit-Position: refs/heads/master@{#60782}
-
Clemens Hammacher authored
The shared engine tests started flaking. They are broken since some time, because the shared pointer to the {NativeModule} has temporary additional users during compilation (in the {BackgroundCompileScope}). This CL fixes the test by just removing the checks for use counts. R=mstarzinger@chromium.org Bug: v8:9117 Change-Id: Ia55ce66426f8d85c0ed8e4185aa6e507a6d327ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564056 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Auto-Submit: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60781}
-
Tobias Tebbi authored
This adds references to HeapObject fields to Torque. The syntax is based on Rust (which is essentially C pointer syntax). The type &T is a reference to T (which must be a scalar type for now). We can create references from field access expressions, using the addressof(&) operator: &obj.fieldname To read or assign a reference, we use the dereference(*) operator: *someref = *otherref This CL also uses references internally normal class field accesses, but only if there is no overload for field accessor functions. This allows to have overloaded field accessors for a subtype like FastJSArray. However, there is a change in behavior in that an operator ".fieldname" will stop reference creation and will therefore also stop write access to a class field of the same name. That's why this CL had to add a write overload ".length=" for FastJSArray. References desugar to a pair of a tagged HeapObject pointer and an untagged offset into this HeapObject. On the CSA-side, they are represented by the C++ struct struct TorqueReference { TNode<HeapObject> object; TNode<IntPtrT> offset; }; Bug: v8:7793 Change-Id: Ica6468d47847bd68fb6b85f731cf8fbe142fa401 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557151 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60780}
-
Clemens Hammacher authored
The {code_table_} in {NativeModule} is protected by the {allocation_mutex_}. The {code} and {code_table} accessors did not acquire this lock though. This CL removes the unsafe {code_table} accessor, renames {code} to {GetCode} and protects it by a lock. R=mstarzinger@chromium.org Bug: v8:9112 Change-Id: Id2df68460b4c10291a49b4016b9574e02744e8b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561315Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60779}
-
Benedikt Meurer authored
The field type can always be generalized in-place, even for root maps. There's no need to create defensive copies in this case. This happens for example in the superWrapper in the Speedometer2/EmberJS-Debug test. Bug: v8:8834, v8:9114 Change-Id: Ief05516d0e9d84850c52d2cf8815953ef77d5223 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562131 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60778}
-
Clemens Hammacher authored
On x64, we allocate one big code region such that we can use near jumps and near calls. The jump table did not make use of that design yet. This CL changes that by emitting jump table slots as near jumps. This also speeds up patching jump table slots significantly, since far jumps populate the inline constant pool, which is unneeded overhead in this case. As a drive-by, this CL cleans up the API of near_call and near_jmp. The current semantics is broken, and only works because this is only used for WebAssembly calls which are patched anyway after code generation. Also, x64 now uses the same path in test-jump-table-assembler.cc as arm64 to ensure that all targets are within near-call-distance. R=mstarzinger@chromium.org Bug: v8:8916 Change-Id: Iffc34e248b72167307ffdab62dd2212c4ae86a32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561313Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60777}
-
Jaroslav Sevcik authored
Bug: v8:9113 Change-Id: I413d9df34f0bdea9c30db33ad79891218e229341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564053Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60776}
-
peterwmwong authored
Change-Id: Ic31b33ef4c290aee31be2d66295978908f568775 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563410Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Cr-Commit-Position: refs/heads/master@{#60775}
-
Seth Brenith authored
When clearing a DebugInfo, we need to check whether that function is currently executing and, if so, update the on-stack BytecodeArray pointer to refer to the original BytecodeArray. Otherwise, the original BytecodeArray might get flushed, which can cause problems when attempting to resume execution of the function. Bug: v8:9067 Change-Id: Ief28a501294f5a34052e13f618fa084311eaa0b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1548573Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60774}
-
Igor Sheludko authored
... when pointer compression is enabled. Bug: v8:7581, v8:7703 Change-Id: Ie0928f813458d2ffa9159f5098c4f91bf8cee437 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564052 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60773}
-
Clemens Hammacher authored
Some code - especially WebAssembly - does not make use of the code target vector. Unconditionally reserving 100 entries adds unnecessary overhead e.g. to jump table patching (~10%). This CL just removes this reservation. R=mstarzinger@chromium.org Bug: v8:8916 Change-Id: I671820f3eb413fa2d03cef4bbf06adfc7a585266 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559868Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60772}
-
Jaroslav Sevcik authored
The current NumberEqual check ignores -0 when it is stored to a constant unboxed double field containing 0. Bug: v8:9113 Change-Id: I7eb59ca8af09ab7317da3c6ce9c9cedad81f6cae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561317Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60771}
-
Benedikt Meurer authored
This doesn't seem to provide any noticable performance wins, and just adds more (generated) code. On a synthetic micro-benchmark for accessing dictionary elements I was able to measure only a <1% difference for loads and barely 1-2% for stores. That doesn't seem to be enough of a reason to add four unrolled iterations of the lookup loop in all kinds of places. Bug: v8:5787, v8:8834 Change-Id: Iab8f71bf70a5518589ed4999a5be21d268ba1081 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563774 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60770}
-
Michael Achenbach authored
This will allow to distinguish between the standard runner and the num fuzzer on the infra side when generating flako command lines. The value could be inferred, but it'd be more confusing. Bug: v8:8971 Change-Id: I78f5104135d1c7fd7d98bceb4b17897e79421455 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564050 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#60769}
-
Igor Sheludko authored
... and ensure that runtime behaviour is in sync with the IC code. Bug: chromium:950747, v8:9113 Change-Id: Ied66c9514cbe3a4d75fc71d4fc3b19ea1538f9b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561319Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#60768}
-
Toon Verwaest authored
Previously we'd need to eagerly compile upon access to function.length for a lazy function. The preparser already computes function.length, however, so we can store that information in the already available preparse data. Change-Id: I19007c9db5839e8038291fb4433866303935f089 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564190 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#60767}
-