- 18 Dec, 2019 20 commits
-
-
Frank Tang authored
Implement the ECMA402 localeMatcher: "best fit" option by using ICU LocaleMatcher API. Bug: v8:7051 Change-Id: I3d7c1ee39a5c649a5f500429f2b41329346a1a78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943050Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#65507}
-
Joshua Litt authored
Change-Id: I9fa2276b9e27fe51d15be3c1afb34633b53d1230 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973969Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#65506}
-
Z Nguyen-Huu authored
In setting breakpoint in wasm, we can find wasm script from location but in removing a breakpoint, only breakpoint id is provided. For wasm, we have a list of all BreakPointInfo objects attached to the Script. From breakpoint id, we iterates all scripts to find the targeted breakpoint and remove it. Bug: chromium:837572 Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65505}
-
Liviu Rau authored
Bug: v8:9633 Change-Id: I44e8e2d036552f47c82441cd0484807ca34d0e14 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973739 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65504}
-
Nico Hartmann authored
This CL implements enums in Torque in three steps: 1.) It implements necessary changes to Torque's type system. In particular, the constraints on constexpr types are relaxed such that constexpr types can exist without a corresponding non-constexpr version. Furthermore, constexpr and their non-constexpr counterpart need not be of the same kind of type. This allows an AbstractType to have a UnionType as its non-constexpr counterpart. 2.) The enum feature itself is realized as a pure desugaring in the parser, where all required types, constants and macro specializations (like FromConstexpr<>) are generated from a simple enum declaration, such that enum entries are not just constants, but are namespace scoped and have distinct types so that they can be used within typeswitch constructs. 3.) Almost all of the existing constants defined in torque (.tq files) are ported to new enum definitions. Bug: v8:10053 Change-Id: I72426d3b1434f301fd690847e15603de0dc1021b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964392 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Maya Lekova authored
Fixed: chromium:1035331 Change-Id: I6ef31910b2e22e4687412c45cc14c98669c6bd3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973733Reviewed-by:
-
Joey Gouly authored
This is similar to the change made to IsImmLSPair in 9f7ae50a. Change-Id: I17a7cc95661542efb5711df0639cc11ac7926702 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1971950 Commit-Queue: Joey Gouly <joey.gouly@arm.com> Reviewed-by:
-
Thibaud Michaud authored
This is a reland of c509bb8c Original change's description: > Cache native modules in the wasm engine by their wire bytes. This is to > prepare for sharing {Script} objects between multiple {WasmModuleObject} > created from the same bytes. This also saves unnecessary compilation > time and memory. > > R=clemensb@chromium.org > > Bug: v8:6847 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916603 > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65296} R=clemensb@chromium.org Bug: v8:6847 Change-Id: I8839c9ec96dc4141cf3c30916a62ccf86f5463ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960287 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This reverts commit 5377e72c. Reason for revert: Looks like the relevant graphs didn't recover after this revert, which suggests that the regression was an unrelated secondary effect. Relanding the original change since the revert did cause some microbenchmark regressions. Original change's description: > Revert "[ic] Load name/context lazily in LdaNamedProperty" > > This reverts commit 347092ac. > > Not a clean revert, since other changes got baked on top, but rather > a manual removal of LoadLazyICParameters. > > Reason for revert: Seems to actually regress bindings perf tests (see > bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't > seem to improve performance elsewhere, and increases complexity. > > Original change's description: > > [ic] Load name/context lazily in LdaNamedProperty > > > > Introduces LazyLoadICParameters which allow a LazyNode for context and > > name. These aren't used on the fast path, so we want to avoid reading > > them for both performance and register pressure reasons. > > > > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62539} > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: chromium:981797 > Bug: chromium:982630 > Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65205} TBR=leszeks@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:981797, chromium:982630, v8:10059 Change-Id: I13754de06c83439e03e22cfaa7a14ce454076db9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973730Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65499}
-
Shu-yu Guo authored
For supporting use of dictionaries during GC, such as in the JS WeakRef implementation. Bug: v8:8179 Change-Id: Ide3f5c45d2602f13a1bcb1968b36f08881067090 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1972427Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#65498}
-
Simon Zünd authored
When V8 throws an uncaught exception, we store a JSMessageObject with a stack trace and source positions on the isolate itself. The JSMessageObject can be retrieved by a TryCatch scope and is used by the inspector to provide additional information to the DevTools frontend (besides the exception). Introducing top-level await for REPL mode causes all thrown exceptions to be turned into a rejected promise. The implicit catch block that does this conversion clears the JSMessageObject from the isolate as to not leak memory. This CL preserves the JSMessageObject when the debugger is active and stores the JSMessageObject on the rejected promise itself. The inspector is changed to retrieve the JSMessageObject in the existing catch handler and pass the information along to the frontend. Drive-by: This CL removes a inspector test that made assumptions when a promise is cleaned up by the GC. These assumptions no longer hold since we hold on to the promise longer. Bug: chromium:1021921 Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit cb2090cd. Reason for revert: Still fails with custom snapshot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/29200 Original change's description: > [test] Enable compiler/deopt-array-builtins on gc_stress > > Bug: v8:10035 > Change-Id: I296e6b8a087e081d2f4d2fa15067e755e2ee3585 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970212 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Mythri Alle <mythria@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65493} TBR=mythria@chromium.org,mslekova@chromium.org Change-Id: I4d7c1537136ed1d5c42f7a7c6c94db8987c9b9ec No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10035 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973734Reviewed-by:
-
Dan Elphick authored
Allocate memory more quickly so the test completes faster. (On the ARM simulator tests with slow asserts and verify-heap, it was taking around 20 minutes). Change-Id: I6b4d0a4788817c4f996a073cc3fdf8b69d11bc40 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973731Reviewed-by:
-
Shu-yu Guo authored
Nullify is already defined in an -inl.h, so there is no need for the extra functionality (and overhead) of std::function. Bug: v8:8179 Change-Id: I0b149a962409503a9fde150aa1241de74870533e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1972426Reviewed-by:
-
Mythri A authored
Bug: v8:10035 Change-Id: I296e6b8a087e081d2f4d2fa15067e755e2ee3585 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970212Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#65493}
-
Nico Hartmann authored
This reverts commit 9f18e55f. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/29660 Original change's description: > [TurboFan] Don't serialize read-only heap objects > > Read-only heap objects are immutable and immovable. It is safe to access > these objects directly from the heap. Not having to serialize them > reduces the time we spend on main thread especially for TurboProp. > > Bug: v8:9684 > Change-Id: Ibabb7076af50c9007d2a8ed57fe257406958fb6a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955596 > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Mythri Alle <mythria@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65490} TBR=mvstanton@chromium.org,neis@chromium.org,mythria@chromium.org,mslekova@chromium.org Change-Id: If2d8649cdc083f7d064684352501320a96a1ba2c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973732Reviewed-by:
-
Sigurd Schneider authored
This CL adds an argument to the heap profiler that allows to control whether global objects (e.g. 'window' in JavaScript) are treated as roots in the heap snapshot. Doing so hides blink-internal details and is often a good choice when user-JS leaks are investigated. Sometimes, however, this introduces spurious retainer cycles, which are hard to debug. Previously, this option was exposed as a V8 flag. The blink implications of the build-time V8 flag are now available via the new blink flag `enable_additional_blink_object_names`. Tbr: hpayer@chromium.org Bug: chromium:1034504 Change-Id: Ibe9412917ae598a3ff0c3dc956ab0bc179f50a21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967387Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Mythri A authored
Read-only heap objects are immutable and immovable. It is safe to access these objects directly from the heap. Not having to serialize them reduces the time we spend on main thread especially for TurboProp. Bug: v8:9684 Change-Id: Ibabb7076af50c9007d2a8ed57fe257406958fb6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955596Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Jakob Gruber authored
Bug: v8:9972 Change-Id: Ic1d18586c92536575c9bf4e7b3d2758b44acab30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954389 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2da4a4a..471c567 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b119e4e..0124932 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ba4699f..5e2debe Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/4225f68..9a6352a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a9190d6..cd8fb02 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ica53feaf4a4e1a4c4621ed2a3fc5816ad25b5afb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973470Reviewed-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@{#65488}
-
- 17 Dec, 2019 20 commits
-
-
Seth Brenith authored
This change implements support for reading and writing bitfields from Torque code, and adds a couple of unit tests for this functionality. As Tobias suggested, the LocationReference for a bitfield access contains a nested LocationReference to where the bitfield struct is stored, so that store operations can read the original value, update part of it, and write it back. Bug: v8:7793 Change-Id: I1004a5c7fcb6cf58df5ad50109b114bf89c80efc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957841 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Maya Lekova authored
Add a --max-serializer-nesting flag which defaults to 25. Fixed: chromium:1034768 Change-Id: Ib68f26ce4bf53db297b25d16a046d275beaec642 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969895 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Change-Id: I2de7128210313e40d3c310edd72658180f1ee110 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1968165Reviewed-by:
-
Ulan Degenbaev authored
This is a reland of 83786cb4 Original change's description: > Delay setting up deserialized JSArrayBuffer > > Setting up JSArrayBuffer may trigger GC. Delay this until we > are done with deserialization. > > R=ulan@chromium.org > > Bug: chromium:1033395 > Change-Id: I6c79bc47421bc2662dc1906534fc8e820c351ced > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965580 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65441} Tbr: yangguo@chromium.org Bug: chromium:1033395, chromium:1034059 Change-Id: I89d05768f52a480400d9c6f5aaaa233c5d5ba126 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969896 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit 53308bf7. Reason for revert: Fails on multiple arm bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12441 Original change's description: > [csa] use JSGraph to create constants in CodeAssembler > > Now that CodeAssembler uses optimizing TurboFan passes, creating > constants without using the caching implemented in JSGraph leads to > problems, since value numbering only works properly if all constants > in the graph were introduced through the cache. > To mitigate this, this CL creates the JSGraph earlier so that > CodeAssembler can already use the same JSGraph used by later TurboFan > optimizations. > For other uses of RawMachineAssembler, everything stays as before. > > This issue is creating bot failures in > https://chromium-review.googlesource.com/c/v8/v8/+/1958011 > > Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65477} TBR=tebbi@chromium.org,mslekova@chromium.org Change-Id: I6df6782adfb40632f51681942efab9b591f72cab No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969901Reviewed-by:
-
Clemens Backes authored
MSVC wants the static cast, even if the constant fits in the narrower type anyway. R=ahaas@chromium.org Change-Id: I40043c02db1524ac591f6dcea14333695a53d028 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924356Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65482}
-
Clemens Backes authored
For out-of-line code, we need to generate the debug side table information at the point where the out-of-line code is being triggered, not when it is emitted (at the end of the function). This CL also adds more tests to check the actual content of the debug side table in different scenarios. R=jkummerow@chromium.org Bug: v8:10019 Change-Id: I7714c86ee7edc4918b5ecc97cbded84c27b00e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967388Reviewed-by:
-
Ulan Degenbaev authored
This adds heuristics to perform young and full GCs on allocation of external ArrayBuffer backing stores. Young GCs are performed proactively based on the external backing store bytes for the young generation. Full GCs are performed only if the allocation fails. Subsequent CLs will add heuristics to start incremental full GCs based on the external backing store bytes. This will allow us to remove AdjustAmountOfExternalMemory for ArrayBuffers. Bug: v8:9701, chromium:1008938 Change-Id: I0e8688f582989518926c38260b5cf14e2ca93f84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803614 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65480}
-
Maya Lekova authored
Bug: chromium:1034203 Change-Id: I225fa6416d443802b063e149da6e6fca0a176bb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969898 Auto-Submit: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Zhang, Shiyu authored
This is a reland of 5f5b4b04 Original change's description: > Support Intel VTune ITT API > > Add VTune domain support extension to use VTune Domain/Task API and > tagging trace data for particular JS code block. > > How to use: > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient > file to download intel/ittapi by 'gclient sync' > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true' > 3. Run d8 with flag '--enable-vtune-domain-support' > > The Vtune Domain/Task API can be invoked from JS to mark JS code block. > You can mark the start of a JS task by > vtunedomainmark(domain_name, task_name, "start") > and the end of a task by > vtunedomainmark(domain_name, task_name, "end") > Tasks can nest. > > The VTune API (ittapi) is integrated as an external third party library > while the v8_vtune_jit also relies on the VTune ittapi. We have another > patch almost ready which refactors the v8_vtune_jit related code to > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit > code after this patch stabilized and landed. > > > Contributed by fanchen.kong@intel.com > > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490 > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65409} Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
Now that CodeAssembler uses optimizing TurboFan passes, creating constants without using the caching implemented in JSGraph leads to problems, since value numbering only works properly if all constants in the graph were introduced through the cache. To mitigate this, this CL creates the JSGraph earlier so that CodeAssembler can already use the same JSGraph used by later TurboFan optimizations. For other uses of RawMachineAssembler, everything stays as before. This issue is creating bot failures in https://chromium-review.googlesource.com/c/v8/v8/+/1958011 Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329Reviewed-by:
-
Clemens Backes authored
If --perf-prof is specified, we commit the whole code range at once, and never update the {total_committed_code_space_} counter (see {WasmCodeManager::Commit} and {WasmCodeManager::Decommit}). Hence we should also not decrement that counter when the native module dies. R=jkummerow@chromium.org Bug: chromium:1032753 Change-Id: I9a40f1a1322485d7142ed56f5c9365305aa0e056 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969790Reviewed-by: -
Dan Elphick authored
Since RecordStats during GC, (when it fails to recover enough memory), it unsafe for it to allocate any memory. Thus it cannot call PrintStack which can call SharedFunctionInfo::EnsureSourcePositionsAvailable and which may allocate, so this removes the call to PrintStack which is apparently not useful for debugging anyway. Bug: chromium:1032087 Change-Id: I94feeaab1445f7fd4f770a20197546fc40c77390 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967377Reviewed-by:
-
Toon Verwaest authored
Objects in arrays take the shape of the object right before as feedback to speed up object creation. If a subsequent object with the same shape has a member that also has the same shape, that member can cause the feedback map to be deprecated. To avoid confusion, we now update (dedeprecate) the feedback map before use. Thanks a bunch Seth Brenith for figuring out the issue! Bug: chromium:1029077 Change-Id: I047b1acfd4906616a2302f253ab9cd29272bdc79 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970211 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
port 0f8769df https://crrev.com/c/1967379 Change-Id: If756f5ea84657151a807d02a7407dadc959f06e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970975 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Mythri A authored
In this test we expect that the feedback vector is not flushed so we retain what we have learnt from the earlier executions. If we flush the earlier feedback the code might deoptimize again and the test fails. Hence adding --no-stress-flush-bytecode and --no-flush-bytecode flags. Bug: v8:10035 Change-Id: Ia71748e83d64a731f595fed7f5b85a8dafa2b31a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969850 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Add pointer-sized field extension to the JSArrayBuffer class. Only reserve space for this field when feature is enabled for now. Bug: v8:10064 Change-Id: Idb6fdcdce2a048e6aed9a892bc46ce029e1119f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1956166Reviewed-by:
-
Maya Lekova authored
MapRef::GetStrongValue now returns an Optional to account for the case where we can't figure out the name of the bound function during serialization. We could reach out to the heap in the future in this case. Fixed: chromium:1034203 Change-Id: I9fa81921b5dbd8bc9f68aa3c10921bc01b695a6b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967386Reviewed-by:
-
Peter Marshall authored
Add an API on Isolate that returns a sorted vector of code pages allocated within V8. The implementation is designed to be signal-safe, so that the user (the UMA sampling profiler) can access this information from a signal handler, where allocation and taking locks is prohibited. This CL adds the machinery for maintaining the list of allocated code pages. Further CLs will modify the Unwinder API itself to accept the code pages provided by this API. The unwinder API currently uses the reserved virtual-memory range called the CodeRange to identify where all V8 code objects live, but this doesn't exist on arm32 or any 32-bit platform, so this approach adds a way to expose the location of all valid V8 code objects in a signal-safe way for use by the UMA sampling profiler. On 64-bit, this API always gives the code_range and embedded_code_range, and does not maintain a vector of code pages. This is so that we have a unified API on 32 and 64-bit that can be used in exactly the same way by embedders. Design doc: https://docs.google.com/document/d/1VGwUult5AHLRk658VetwEHMOmDDxA2eDQs9lDFMZTE0 Bug: v8:8116 Change-Id: I732509a45121fc54853182481c24d1083275afce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564068 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/03d0c36..2da4a4a Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/69337c3..b119e4e TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I6f83c95169248851b32bf2ec4f95144b8df295fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970152Reviewed-by:
-
