- 19 Jan, 2021 33 commits
-
-
Zhi An Ng authored
Code sequence from https://github.com/WebAssembly/simd/pull/379. Bug: v8:11002 Change-Id: I47c1090d792f8cbb9d7846ace9a4f996d0c460b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626717Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72174}
-
Milad Fa authored
Port 624030e9 Original Commit Message: 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. R=gsathya@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: If5918721117e87579a3c6a2a4ed6245bd033a88e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636840Reviewed-by:
Junliang Yan <junyan@redhat.com> Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72173}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I7900d041ff1331991d14e2766a6760b69f37622e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637230Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72172}
-
Seth Brenith authored
This would be useful for ForInPrepare. Syntax is unchanged; Torque should now do the right thing for builtins that return a two-element struct. More elements than that is still not supported. Bug: v8:7793 Change-Id: Ic315699402203aba07e906ff6e029834ec0061c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596498Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72171}
-
Zhi An Ng authored
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for the interpreter. This is the first instruction of its kind, a post-mvp, unary operation that takes one immediate. Which is why there are more changes to the decoder than usual. Bug: v8:11297 Change-Id: Ib5c58965e0cba8d7a395b0dc57673110bc60e87c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617385Reviewed-by:
-
Marja Hölttä authored
1) Computed property keys (esp functions in them) shouldn't be inside the object literal scope. 2) I was using an imprecise "maybe uses super" and storing it to preparse data. This won't fly, since it pollutes sister scopes and leads to confusion wrt whether an object literal needs a home object or not. Made it precise (mostly cancelling changes in the original CL). 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for this_function (which made it used) -> inconsistent scopes between parsing and preparsing. 4) MultipleEntryBlockContextScope was messing up the accumulator Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 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, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220Reviewed-by:
-
Liviu Rau authored
Bug: chromium:1166989 Change-Id: I6eca7745ee4457d86ecda65a3972011899bac9c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637219 Auto-Submit: Liviu Rau <liviurau@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72168}
-
Sathya Gunasekaran authored
`last` indicates that it's the last element of the list but in reality this supposed to indicate the previous entry in the list. Rename this to something more clearer. Change-Id: I26c9a1fca02cf6b10d0447768da694d590a43932 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637229Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72167}
-
Ross McIlroy authored
Moves the serialization of the initial set of maps read from the native context from the forground serialization phase to a new background serialization phase. BUG=v8:7790,v8:9684 Change-Id: Id408e5c3096e832cf30106eb8fb7d65518432e06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613028 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Seth Brenith authored
On arm64, Windows Performance Recorder gets confused by the fact that fp in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the caller frame. The expected usage of fp is documented in [1]: The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack. In slightly more detail, the Windows function RtlWalkFrameChain is responsible for generating stack traces during profiling with Windows Performance Recorder, and that function relies on the rule quoted above. Notably, it does not make any effort to read the unwinding data that one could obtain with RtlLookupFunctionEntry. Stack walks using that data, such as those performed by WinDbg and the cctest StackUnwindingWin64, work fine. It would be convenient if we could use fp in a more standard way during JSEntry so that Windows profiling tools work correctly. (We can also reduce JSEntry by two instructions in doing so.) Both arm and arm64 currently put a -1 value on the stack at the location that fp points to. This could prevent accidental access during the epilog of JSEntry, where fp might be zero. However, we believe that this protection is no longer necessary, and any bug that causes a read from fp during the end of JSEntry would cause various CQ failures. [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160 Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72165}
-
Clemens Backes authored
The test was explicitly tiering up or down a module, without respecting other isolates. Thus it was failing in multi-isolate mode. This CL removes two runtime functions which do not make sense in a multi-isolate setting (and were only used in this one test), and replaces them with runtime functions that mimic what enabling/disabling the debugger domain does: As long as there is at least one isolate which needs modules to be tiered down, we keep them tiered down. R=thibaudm@chromium.org Bug: v8:10359, v8:10099 Change-Id: Ia85f4ea29ba6a6bb54aca54a48fadd351121d3eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637231Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72164}
-
Clemens Backes authored
The engine can be retrieved from the NativeModule, hence avoid passing it explicitly. R=ahaas@chromium.org Change-Id: I38f9bdb9624006da8311e57c3e53327654b6e85a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637855Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72163}
-
Georg Neis authored
Change-Id: Ifad7bbafc8b7c7ff8cf9140b9227cb9c67370fcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637856 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72162}
-
Jakob Gruber authored
The helper encapsulates the `x - x` pattern to silence NaN `x`. Bug: v8:7519 Change-Id: Ia633272d7b7cc350c7e4db07e271e0192c68019f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637232 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Junliang Yan authored
Change-Id: I3803e3f7916827b3b9853c8c3a3ce6806cc2daac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636054 Commit-Queue: Junliang Yan <junyan@redhat.com> Reviewed-by:
-
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:
-
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:
-
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:
-
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:
-
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:
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:
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:
-
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 7 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:
-
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:
-
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:
-
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:
-
