- 11 Apr, 2019 32 commits
-
-
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: -
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: -
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:
-
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:
-
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:
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:
-
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:
-
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:
-
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 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:
-
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 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:
-
Michael Achenbach authored
This has no logic changes intended. Bug: v8:8971 Change-Id: I6d35096cd5e0ea189006ba7a5663606f101ccab9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564051Reviewed-by:
-
tzik authored
MicrotasksScope has accidentally ignored the given MicrotaskQueue instance when it's scoping out. That confused the embedder to start using the non default MicrotaskQueue. Change-Id: Id345605cf6520cd073429b08698de75f7681d93c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563836Reviewed-by:
-
Benedikt Meurer authored
This adds a new flag --modify-field-representation-inplace (enabled by default), which lets the runtime perform field representation changes for Smi to Tagged or for HeapObject to Tagged in-place instead of creating new maps and marking the previous map tree as deprecated. That means we create (a lot) fewer Maps and DescriptorArrays in the beginning and also need to self-heal fewer objects later (migrating off the deprecated maps). In TurboFan we just take the "field owner dependency" whenever we use the field representation, which is very similar to what we already do for the field types. That means if we change the representation of a field that we used in optimized code, we will simply deoptimize that code and have TurboFan potentially later optimize it again with the new field representation. On the Speedometer2/ElmJS-TodoMVC test, this reduces the total execution time from around 415ms to around 352ms, which corresponds to a **15%** improvement. The overall Speedometer2 score improves from around 74.1 to around 78.3 (on local runs with content_shell), corresponding to a **5.6%** improvement here.
🎉 On the CNN desktop browsing story, it seems that we reduce map space utilization/fragmentation by about 4-5%. But since we allocate a lot less (fewer Maps and DescriptorArrays) we also significantly change the GC timing, which heavily influences the results here. So take this with a grain of salt.🤷 ♂️ Note: For Double fields, this doesn't change anything, meaning they still create new maps and deprecate the previous map trees. Bug: v8:8749, v8:8865, v8:9114 Change-Id: I694a53f87ae5caeb868fd98a21809b66d4297d35 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: http://bit.ly/v8-in-place-field-representation-changes Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561132 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60764}
-
Z Duong Nguyen-Huu authored
Bug: v8:8952 Change-Id: I5f6574bf5dfd483c7052ac8d4de5217c27e02a03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543335Reviewed-by:
-
Michael Achenbach authored
This is to investigate if higher timeouts mitigate the timeout problems. If not it'd mean somethings actually hanging. TBR=sergiyb@chromium.org Bug: v8:9098 Change-Id: Idd9ae79e6f7bbede79b09498dd1acca429495308 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563970 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Michael Achenbach authored
The previous skip in https://crrev.com/c/1557142 should have only addressed the deopt fuzzer. The test is only very slow there: https://ci.chromium.org/p/v8/builders/ci/V8%20NumFuzz%20-%20debug/5476 TBR=sergiyb@chromium.org NOTRY=true Bug: v8:9098 Change-Id: I9abee3e23fcc65c6089df32eee8e7a7e5444b902 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563773Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/6f0224b..ba0d0b9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f8d4d2d..dc0c991 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/224e075..6379cd3 Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/8e8db13..a42c2f6 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/69c72a6..4ae7482 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f822215..5f253f8 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Id9387595f335c5fceff1dba6066f8440cae0a02d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563210Reviewed-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@{#60760}
-
Shawn Anastasio authored
v8 currently detects ABI by checking OS and endianness, but this is not sufficient to properly detect cases in which the ELFv2 ABI is used on big-endian Linux systems. Update these checks to use additionally use the _CALL_ELF macro in order to properly handle such cases. This issue was initially discovered by the Adélie Linux team. Change-Id: Iefc0510963d93e59d6c62469a505c70c594bb14a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1555424Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
-
- 10 Apr, 2019 8 commits
-
-
Paolo Severini authored
In file include/v8config.h we define: ifdef V8_OS_WIN ... if defined(_M_X64) || defined(__x86_64__) define V8_OS_WIN_X64 true endif and V8_OS_WIN_X64 is supposed to be defined when targeting X64 on Windows only. But this is wrong because V8_OS_WIN_X64 gets defined also on an ARM64 builds when the host machine is X64. It should instead be: ifdef V8_OS_WIN ... if defined(V8_TARGET_ARCH_X64) define V8_OS_WIN_X64 true endif Bug: v8:9090 Change-Id: I88e4c46bb6df1efa2070d4e1785081d71df96f0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554222Reviewed-by:
-
Paolo Severini authored
This CL makes sure that Crashpad on Chromium will behave exactly like it did before we added code to emit unwinding info, even when FLAG_win64_unwinding_info is not set. In particular, before merging the Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/1474703/ that modifies Crashpad to use the new function SetUnhandledExceptionCallback(), we need to make sure that Isolate::Init() will call win64_unwindinfo::RegisterNonABICompliantCodeRange() even when FLAG_win64_unwinding_info is false. In that case RegisterNonABICompliantCodeRange will only register unwind info to invoke the Crashpad exception handler for unhandled exceptions. Note that RegisterNonABICompliantCodeRange will be a no-op with the current Crashpad code that never calls SetUnhandledExceptionCallback(). Bug: v8:8661 Change-Id: I63d845e9dca79ddd5978dfb43b626ace50078e80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554119Reviewed-by:
-
Frank Tang authored
Bug: v8:8318 Change-Id: I1c4bb26270c4ea9ede99a131f804568e6f721fc6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560657Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60756}
-
Ben Smith authored
When getting the starting address of a data segment, you can't use `&vector[offset]` if offset is equal to the length of the vector. This can happen when the length of the segment is 0. The fix is to use Vector::SubVector instead. Bug: v8:9106 Change-Id: Icf8968cc246c6d217d8061f76fb2631c2292433c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560405 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
The wasm engine is the same for all units, thus we should store (or get) it in the compilation task, and not store it duplicated in each compilation unit. R=mstarzinger@chromium.org Bug: v8:8916, v8:8343 Change-Id: Id4b062b5b8a52228b4d6051a67e025088a61d466 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559863 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Maya Lekova authored
Bug: v8:8746, v8:9057 NOTRY=true Change-Id: Idf6b204469e0f8b547014465ecfc46388a05f264 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561318 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Jaroslav Sevcik authored
If the runtime does not transition in keyed store IC miss handler, avoid generating transitioning handler since this could make the receiver map non-stable. (The optimizing compiler does not like non-stable fast prototype maps.) Bug: chromium:950328 Change-Id: I113880d2033518e3eb8fd11df1599e56a67d7fd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559867 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
Sergiy Belozorov authored
R=machenbach@chromium.org, tmrts@chromium.org No-Try: true Bug: chromium:841700 Change-Id: I18552e928223dd8ea03ac518f6b1b2460d10135d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559851 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
-
