- 19 Jan, 2021 18 commits
-
-
Benedikt Meurer authored
This was originally proposed by yangguo@ on the original CL that introduced this, but back then it looked easier to put the map cache onto the global object than on the native context. However it turns out that this is indeed quite strange and also not necessarily supported (we got crashes from the wild indicating that the `Object::GetProperty()` might fail on the global object). So this CL simplifies the original design and just puts the map cache onto the native context like with do with other context specific maps. Fixed: chromium:1167399 Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241 Change-Id: Ie16f892dd19b55b4c49e9d4829cab3c24ae64ad3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637226 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72159}
-
Clemens Backes authored
This reverts commit 8703c38d. Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview) Original change's description: > [compiler] Emit a function-entry stack check on OSR-entry > > This CL extends the smarter function-entry stack check logic (see > v8:9534) to OSR'd code. These smarter stack checks prevent > overflowing the stack during deoptimization. > > The challenge for both function-entry (FE) and OSR-entry (OE) stack > checks is that there is no dedicated physical StackCheck to > deoptimize into. For more context: the physical StackCheck bytecode > was removed in crrev.com/c/1914218. > > FE stack checks solve this by using a marker bailout id to signify > a deopt bytecode offset before the first bytecode. > > In this CL, OE stack checks take a similar approach by using the > OSR'd loop's JumpLoop bytecode, which is conceptually immediately > before the OSR'd loop header. > > When a stack overflow at an OE stack check occurs: %StackGuard > may cause a lazy deopt on return to the optimized OSR code, > causing re-execution of the JumpLoop handler in the > InterpreterEnterBytecodeAdvance builtin, ultimately continuing > execution the interpreter at the first bytecode of the OSR'd loop > header. > > Bug: chromium:1034322, v8:9534 > Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872 > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72153} TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1034322 Bug: v8:9534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72158}
-
Junliang Yan authored
Change-Id: I42ff5501bec10ef5230ea06d5feb9adc5be0d875 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633731Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#72157}
-
Clemens Backes authored
The inspector fuzzer is terminating the isolate after two seconds. At this point, we can be in pretty much any state, and any further JS execution would fail. This CL fixes an issue where we got the termination signal when creating a context for a regexp (while installing extensions). There might be more places that need fixing, but with this CL the linked issue does not reproduce locally any more, so it's a step forward. R=szuend@chromium.org, bmeurer@chromium.org Bug: chromium:1166549 Change-Id: I33b48205b71877aca6cfe5267f353fa899bfa05c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636153Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72156}
-
Michael Lippautz authored
Termination GCs are used to destroy remaining C++ object on the managed heap to free potential off-heap memory. This is important for gracefully shutting down workers. Drive-by: Add guard prohibiting recursive sweeping calls on the mutator thread. Bug: chromium:1056170 Change-Id: I02ea3b632d38f5beab18cc8f077cf717ed877909 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2631504 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72155}
-
Milad Fa authored
Bug: v8:10972 Change-Id: Id7b17ad54f0a6a1a8b3eb04bb81b2ec94bca921b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2635796Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72154}
-
Jakob Gruber authored
This CL extends the smarter function-entry stack check logic (see v8:9534) to OSR'd code. These smarter stack checks prevent overflowing the stack during deoptimization. The challenge for both function-entry (FE) and OSR-entry (OE) stack checks is that there is no dedicated physical StackCheck to deoptimize into. For more context: the physical StackCheck bytecode was removed in crrev.com/c/1914218. FE stack checks solve this by using a marker bailout id to signify a deopt bytecode offset before the first bytecode. In this CL, OE stack checks take a similar approach by using the OSR'd loop's JumpLoop bytecode, which is conceptually immediately before the OSR'd loop header. When a stack overflow at an OE stack check occurs: %StackGuard may cause a lazy deopt on return to the optimized OSR code, causing re-execution of the JumpLoop handler in the InterpreterEnterBytecodeAdvance builtin, ultimately continuing execution the interpreter at the first bytecode of the OSR'd loop header. Bug: chromium:1034322, v8:9534 Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72153}
-
Milad Fa authored
Bug: v8:10972 Change-Id: I76d795c1f4cf0fc39ca4b4f4ea72c8e817c17da5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632699Reviewed-by:
-
Sathya Gunasekaran authored
There's no need for these extra protector checks as the actual checks are now fast -- we don't have to compare against function objects in every context but instead just do a very quick instance type check. Bug: v8:11256 Change-Id: I40cdf40c8c85e39354bcbd32a7808cd083c8e45b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2598586 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#72151}
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:11319 Change-Id: If24b1ba929bce2e4268a794930c325aaebcfa556 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637222Reviewed-by:
-
Ross McIlroy authored
If a register is used for both input and output by a SAME_INPUT_OUTPUT operand, then it represents a different virtual register for the end use-position of an instruction (since that will become the output's virtual register). It therefore can't be used to represent the input virtual register for any input operands that are USED_AT_END. BUG=chromium:1163715,v8:9684 Change-Id: I8dc0008ba81d5f1d0e38091b6dc013725c62b1b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632700Reviewed-by:
-
Z Nguyen-Huu authored
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI Modify that C++ backend so that it can emit either runtime C++ or postmortem debugging code. When in postmortem debugging mode, the overall code structure would look similar with some difference: 1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor. 2. Instead of runtime class names like String, we use uintptr_t 3. When loading data from objects, instead of TaggedField<T>::load or Object::ReadField (which read from the current process), we use the MemoryAccessor and read data from the debuggee process. 4. Return values should be wrapped in the Value struct. Implement the debug accessors for complex length expressions and add test for such class (SmallOrderedHashSet). Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72148}
-
Paolo Severini authored
This is a reland of 860fcb1b - Disabled the tests for this feature in V8-lite mode (the original change broke V8-lite tests) - Also modified test console-profile-wasm.js that was brittle with this change because it assumed that there was always a JS-to-Wasm wrapper but this is not the case when the TurboFan compilation completes before the Liftoff-compiled code starts to run. More changes in Patchset 8: - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering, into a new phase, wasm-inlining that reuses the JSInliner reducer. The doc https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# describes the new logic. - Fixed a couple of small issues in wasm_compiler.cc to make sure that the graph "JSToWasm Wrapper" subgraph has a valid Control chain; this should solve the problem we had inlining the calls in functions that can throw exception. Original change's description: > Faster JS-to-Wasm calls > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > the basis of the signature of a Wasm function to call, and whose task > is to: > - set "thread_in_wasm_flag" to true > - convert the arguments from tagged types into Wasm native types > - calculate the address of the Wasm function to call and call it > - convert back the result from Wasm native types into tagged types > - reset "thread_in_wasm_flag" to false. > > This CL tries to improve the performance of JS-to-Wasm calls by > inlining the code of the JS-to-Wasm wrappers in the call site. > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > this kind of calls. A 'JSWasmCall' node is associated to > WasmCallParameters, which contain information about the signature of > the Wasm function to call. > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments > of the Wasm function, when the conversion is not necessary. > The actual inlining of the graph generated for this wrapper happens in > the simplified-lowering phase. > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > lazy deoptimizations that can happen if the Wasm function callee calls > back some JS code that invalidates the compiled JS caller function. > > Bug: v8:11092 > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#71824} Bug: v8:11092 Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72147}
-
Sathya Gunasekaran authored
This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. Bug: v8:11256 Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Jakob Gruber authored
StateValuesAccess iterates over actual (non-adapted) arguments, thus we must be careful not to iterate past their end when handling rest args and advancing through the initial non-rest-args. Tbr: neis@chromium.org Bug: chromium:1167709,chromium:1166136 Change-Id: If506050a5518f394e0dcdbf39840b99923d4cbae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637213 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Andreas Haas authored
For asynchronous compilation, the beginning and end of compilation are marked with different trace events. To allow to connect these events, a compilation id is added to the start and end events. Note that the compilation id is not added to all trace events to avoid bloating traces. Ids may be added later to these events if necessary. R=clemensb@chromium.org Bug: chromium:1084929 Change-Id: I36ad598d27dea355fcca8992534c91e5a880fdaa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629274 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This reverts commit a80d51d4. Reason for revert: Breaks: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/2042 Original change's description: > [wasm][mac][arm64] Enable OOB trap handler > > R=ahaas@chromium.org,mark@chromium.org,mseaborn@chromium.org > > Bug: v8:11098 > Change-Id: Ic4eb02a96805e49da71f301269567a6e0ac1b843 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519555 > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72136} TBR=mseaborn@chromium.org,ahaas@chromium.org,mark@chromium.org,ishell@chromium.org,zhin@chromium.org,thibaudm@chromium.org Change-Id: I73d868f044f3c362e4a6d65533fccbdb49c51cd3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11098 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637216Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72143}
-
Maya Lekova authored
This reverts commit 4d5b878b. Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263 Original change's description: > [super] Store home object in Context instead of JSFunction > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237 > Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72137} TBR=marja@chromium.org,leszeks@chromium.org Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215Reviewed-by:
-
- 18 Jan, 2021 17 commits
-
-
Junliang Yan authored
Change-Id: I4bb964bee86248b7990e69ac458431c2a489bcd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633730Reviewed-by:
-
Dan Elphick authored
Adds a v8-gn.h file containing defines that are used in the externally-visible headers files like v8.h. This must be included by include/v8config.h which includes it if the GN flag v8_generate_external_defines_header is on. (Currently off by default). To enable the v8config.h file to be included without the other v8 headers (as required by cppgc), this moves it into its own header set which sets up the include path correctly. Also updates some headers to ensure v8config.h is included before using externally-visible defines. Bug: v8:11292 Change-Id: I5be634f4adfbef144bf684071461d64f1cb30899 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608212 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Andreas Haas authored
There was a bug that only the last local with a reference type got initialized to null, all other locals kept the initial value of 0. This CL fixes this bug. Additionally this CL optimizes the code slightly. Before this CL, the null reference was loaded from the instance for every local with reference type. Now the null reference is cached after the first load and then used for all other locals. R=thibaudm@chromium.org Bug: chromium:1167587 Change-Id: Ic11fc76b650e6daa029491154744fc132778f70d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632695 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#72139}
-
Seth Brenith authored
Heap-profiler changes: Currently, a whole lot of types are all reported as just "system" in heap snapshots. With this change, we can use Torque-generated macro lists to easily report type names such as "system / BytecodeArray". Those objects still show up in a single category named "(system)" in the dev tools UI, so they don't clutter the output. For V8 developers or anybody who is interested in an extra-detailed view, this change also includes a runtime flag that instructs V8 to upgrade nodes of type kHidden to type kNative. After a snapshot is collected with this flag enabled, the dev tools UI then shows each internal object type separately. Torque changes: Currently, Torque emits several macro lists containing pairs of (ClassName, CLASS_NAME_TYPE) which can be used to associate instance types with Torque class names. However, some Torque classes are not included in any of these three lists. In cases like the heap profiler, it would be nice to easily generate a complete list including every instance type, so this CL includes two changes: - Include classes in TORQUE_INSTANCE_CHECKERS_MULTIPLE_FULLY_DEFINED even if they're not marked `extern`. I'm not sure what exactly we were hoping to accomplish in filtering by extern-ness, but it's simpler not to and slightly reduces clutter in a couple of files that use that macro list. - Add a fourth macro list for the previously-ignored category: classes which have their own instance type (are not `abstract`), and have subtypes, but do not have their fields defined in Torque. This list contains just a single item (HashTable), but I like the consistency of generating the full set of lists. Change-Id: Ib24953e12ed13ce353206bbec23a52d8f684dfcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610172 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Marja Hölttä authored
This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72137}
-
Thibaud Michaud authored
R=ahaas@chromium.org,mark@chromium.org,mseaborn@chromium.org Bug: v8:11098 Change-Id: Ic4eb02a96805e49da71f301269567a6e0ac1b843 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519555 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Junliang Yan authored
Change-Id: Ia8e8600cabb7e317befca480e734915239e10f69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2634828Reviewed-by:
-
Nico Hartmann authored
This reverts commit ff606a06. This fix makes a handle persistent that was missing in the original CL. Bug: v8:7790, chromium:1158322 Change-Id: I53079f5c32523313cff76130d2a40c3de5bb0638 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629270 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Victor Gomes authored
Removes: - v8_disable_arguments_adaptor GN flag - ArgumentsAdaptorTrampoline - ArgumentsAdaptorFrame class Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Clemens Backes authored
memory.size returns in i64 if memory64 is enabled. This CL fixes typing and adds a decoder test. Execution will be tested and fixed in a follow-up CL. R=manoskouk@chromium.org Bug: v8:10949 Change-Id: I15818a6273b579d0faacec7f77dc813ae9ba218f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632593Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72132}
-
Clemens Backes authored
For memory64, the init expressions for data segments provide a 64-bit value. This CL adds a new {EvalUint64InitExpr} function alongside {EvalUint32InitExpr}. It supports i64.const and global.get operations. R=manoskouk@chromium.org Bug: v8:10949 Change-Id: I58acbb28acb8771a0947f9d5df1c14e6ca0f79cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632589Reviewed-by: -
Sami Kyostila authored
If V8 is running in a context where Perfetto hasn't been initialized (e.g., as part of mksnapshot), don't try to initialize track events either. Since perfetto::Tracing::IsInitialized() was only added recently, we also roll Perfetto to the latest revision. This also requires updating the proto_library GN template together with the underlying libprotobuf dependency. Bug: chromium:1006541 Change-Id: Icec626b7ed78264a81f1a80d73d60be3bde0d908 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632590 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Ross McIlroy authored
The feedback_vector/cell and code fields of a JSFunctionRef are only used when generating code for the function (e.g., for the function being optimized or inlined functions). This CL explicitly serializes these fields only when the function will be used for codegen, otherwise avoiding their serialization. BUG=v8:7790,v8:9684 Change-Id: If76bc0b77e51aa10517699e0a9198358fe77f009 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617083Reviewed-by:
-
Mythri A authored
This cl: https://chromium-review.googlesource.com/c/v8/v8/+/2632588 introduced a bug by bailing out early if we have top tier code early. However, we still need to check if the frame is still interpreted so that we could OSR. The early bailout isn't correct and also the DCHECK isn't correct. This cl removes both. Bug: chromium:1167638, v8:9684 Change-Id: I5a4aa406b05b6cbb5f98b63e015298c5b45160eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632696Reviewed-by:
-
Clemens Backes authored
We are working on getting Liftoff feature complete. Eventually, bailout should only happen if experimental features are enabled. Until we are there, we also need to allow some more bailouts, which should be removed in the near future. This CL adds a check for expected bailout reasons. The new function serves as a burndown list of issues to be fixed. Drive-by: Make some methods constexpr such that they can be used in static assertions. R=ahaas@chromium.org Change-Id: I5d3cd8f49a30d01f89ac6cf5321e1314b63eba40 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629513 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Jakob Gruber authored
FrameState parameters must not be iterated directly since parameters can be encoded into StateValues (i.e. parameter i is not necessarily InputAt(i)). Instead, they should be accessed through the StateValuesAccess helper class. One example: 82: StateValues[sparse:^^^^^^](81, 31, 32, 33, 34, 35) 81: StateValues[sparse:^^^^^^^^](110, 24, 25, 26, 27, 28, 29, 30) 31: NumberConstant[8] 32: NumberConstant[9] 33: NumberConstant[10] 34: NumberConstant[11] 35: NumberConstant[13] Here, node 81 holds multiple parameters. These are properly iterated by the StateValuesAccess class. Bug: chromium:1166136 Change-Id: I12725f83994e1c05571bcba153ff45154b16d93f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625879 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3ecdb5e..43dd249 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f46e9e7..cf567b6 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I22b2eb5734c9578289d1700b1fae88f2c338d3e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2635361Reviewed-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@{#72125}
-
- 16 Jan, 2021 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/670a905..3ecdb5e Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/235cfe4..c38b5ab Rolling v8/buildtools/linux64: git_revision:595e3be7c8381d4eeefce62a63ec12bae9ce5140..git_revision:d62642c920e6a0d1756316d225a90fd6faa9e21e Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b2af2da..f46e9e7 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/091f5ac..dabd965 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ib0c53b119f960f4d8d41d7bd1b4355ea82b0b009 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632878Reviewed-by:
-
- 15 Jan, 2021 4 commits
-
-
Santiago Aboy Solanes authored
This reverts commit 3a6f75ac. Reason for revert: performance regressions https://bugs.chromium.org/p/chromium/issues/detail?id=1163063 Original change's description: > [objects] Remove MakeExternal case for uncached internal strings > > Concurrently accessing internal external uncached strings is not > thread-safe. We are removing a case where we can make such a string > through MakeExternal. > > Bug: v8:7790 > Change-Id: I958062c15cf40ccc330600bb572de98620866e54 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71573} TBR=leszeks@chromium.org,solanes@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: I5dcc734869c3c921eacd89426309141127a85f47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633547Reviewed-by:
-
Santiago Aboy Solanes authored
This reverts commit b3d09001. Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that Original change's description: > [objects] Remove uncached internal external string type > > We shouldn't be creating those anymore since they are not thread-safe. > > Bug: v8:7790 > Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72006} TBR=rmcilroy@chromium.org,leszeks@chromium.org,solanes@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: I4eb1a6b8446fa602eeb5bf29fbf1fe57182cdbf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627605Reviewed-by:
-
Andreas Haas authored
R=thibaudm@chromium.org Bug: v8:7581 Change-Id: I717466f045473015c8d99d1e640492486d05a832 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625886 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Context objects are allocated on the heap and thus should be Data objects. This allows handling them through tracing in the GC through the API. Bug: chromium:1013149 Change-Id: Id3a7bfd57fab19a5669062ccf61c2f8588faf0bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627307Reviewed-by:
-
