- 23 Apr, 2020 1 commit
-
-
Timothy Gu authored
Before ES2015, the ES spec had a [[Class]] internal slot for all objects, which Object.prototype.toString() would use to figure the returned string. Post-ES2015, the [[Class]] slot was removed in spec for all objects, with the @@toStringTag well-known symbol the proper way to change Object.prototype.toString() output. At the time, spec-identical handling without the use of [[Class]] was implemented in V8 for all objects other than API objects, where issues with the Web IDL spec [1] prevented Blink, and hence V8, to totally migrate to @@toStringTag. However, since 2016 [2] Blink has been setting @@toStringTag on API class prototypes to manage the Object.prototype.toString() output, so the legacy [[Class]] handling in V8 has not been necessary for the past couple of years. This CL removes the remaining legacy [[Class]] handling in Object.prototype.toString(), JSReceiver::class_name(), and GetConstructorName(). However, it does not remove the class_name field in FunctionTemplateInfo, as it is still used for the `name` property of created functions. This CL also cleans up other places in the codebase that still reference [[Class]]. This change should have minimal impact on web-compatibility. For the change to be observable, a script must do one of the following: 1. delete APIConstructor.prototype[Symbol.toStringTag]; 2. Object.setPrototypeOf(apiObject, somethingElse); Before this CL, these changes will not change the apiObject.toString() output. But after this CL, they will make apiObject.toString() show "[object Object]" (in the first case) or the @@toStringTag of the other prototype (in the latter case). However, both are deemed unlikely. @@toStringTag is not well-known feature of JavaScript, nor does it get tampered much on API constructors. In the second case, setting the prototype of an API object would effectly render the object useless, as all its methods (including property getters/setters) would no longer be accessible. Currently, @@toStringTag-based API object branding is not yet implemented by other browsers. This V8 bug in particular has been an impediment to standardizing toString behavior. Fixing this bug will unblock [3] and lead to a better Web IDL spec, and better toString() compatibility for all. [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 [3]: https://github.com/heycam/webidl/pull/357 Bug: chromium:793406 Cq-Include-Trybots: luci.chromium.try:linux-rel Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 Commit-Queue: Timothy Gu <timothygu@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67327}
-
- 22 Apr, 2020 29 commits
-
-
Ng Zhi An authored
Load splat opcodes are currently multi-byte, but were not passing the right lengths for decoding of immediates. Bug: v8:10258 Change-Id: I2c93c3f915eaa43a74722cf0285f161d16ef0ff6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154769Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67326}
-
Zhao Jiazhong authored
Port 9f41a584 https://crrev.com/c/2151999 Change-Id: I58b02bebe3802a4c4a66df331913a742a083de9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160688Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#67325}
-
Shu-yu Guo authored
This is a reland of 30c6bd45 Original change's description: > [weakrefs] Ship WeakRef and FinalizationRegistry. > > I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/L04PqDk9eMU > Bug: v8:8179 > Change-Id: I52aaa62cdab981b802fa4a986d60421ef6efcfbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158371 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67295} Bug: v8:8179 Change-Id: If132d88b5a8dbe06ba7a8f80f19f33d9553ca62f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160017Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67324}
-
Thibaud Michaud authored
The multi-value repository was removed from the list of repositories we pull in update-wasm-spec-tests.sh. But the tarball still contains some multi-value tests which should be removed. R=ahaas@chromium.org Change-Id: Ifb96a105c95d09f202a0f23ba50cddaa7ced494b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161074Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67323}
-
Milad Farazmand authored
Test needs to be removed as discussed under https://crrev.com/c/2099445. Change-Id: If026b54ba5d27aea23cb62fe11688d86bcee9df2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161388Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67322}
-
Marja Hölttä authored
There's no reason for it to be a JSArray; it's an internal data member. We only have a slow version for constructing a FixedArray from an Iterable, but since this is not a performance critical code path, it's fine. BUG=v8:9808 Change-Id: I5bcfac4cc545880966421a96d3aa3d899bbf6cd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157371Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67321}
-
Milad Farazmand authored
We are getting the following error due to int overflow: test/cctest/test-code-stub-assembler.cc:3868:28: warning: integer overflow in expression [-Woverflow] factory->NewNumber(2 * kSmiMaxValue), ~~^~~~~~~~~~~~~~ Change-Id: I85b14a5c500b977febcfe7921bea9b25631a9912 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160355Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67320}
-
Shu-yu Guo authored
Bug: chromium:1073263 Change-Id: I5c054e34242a91dafd6788814a39e97075d1035d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160019Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67319}
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I67f7ace62b6c257f4f3ad76fb22eff99e4988e2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158918 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67318}
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I787c9bc9c998c873bf431df13eb3b92044cbc1e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157647Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67317}
-
Dan Elphick authored
Adds override annotation to FreeList subclass destructors. Change-Id: I86034d381a408abe6e6c91ffb062999c0614799d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161071 Commit-Queue: Dan Elphick <delphick@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67316}
-
Ng Zhi An authored
These are almost unused, except for 1 case of Bit, which is probably incorrect. These static helpers can cause subtle error, e.g. instr->Bit(1, 3) does not get you bits 1 to 3, but rather calls the static method Bit(Instr, int). An example of this bug was fixed in https://crrev.com/c/2157799. Change-Id: I98c4464c4315af48b9d36472ffd6f16aa74aa18b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158824Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67315}
-
Jakob Kummerow authored
read_prefixed_opcode() can fail; we must check for that case before using the value it returned. Bug: chromium:1073356 Change-Id: Ic213bd296e9c50dbffd5df8bc94ef0e7695d75a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161068 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67314}
-
Thibaud Michaud authored
The multi-value proposal is now merged in the main spec repository, so: - Remove everything that references the multi-value spec repository - Add --experimental-wasm-mv to the default flags R=ahaas@chromium.org Change-Id: I9f809c21404bb5c1d21eb330748ea51a15688546 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153219 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67313}
-
Milad Farazmand authored
Port 9f41a584 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I1f2acddd880daa392a686b3ebcdb3804114245ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160088Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67312}
-
Ulan Degenbaev authored
This adds the following trace events to help diagnose GC scheduling issues: - V8.MemoryPressureNotification - V8.CheckMemoryPressure - V8.ExternalMemoryPressure Bug: chromium:1072746 Change-Id: If850fc3d0f419395f22ec05b1779797916e39798 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159487Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67311}
-
Anton Bikineev authored
- implemented as a single-linked list with head and tail pointers. The tail pointer is needed for freelist appending; - stores entries in buckets, where bucket[log2(size)] stores entries >= size; - implements worst fit allocation to amortize free list call; - ported from Blink: https://bit.ly/2yC8XKJ. Bug: chromium:1056170 Change-Id: I26cf62c948c95a7cbfecd5f7f22ad975e6b8c732 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157376 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by: 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@{#67310}
-
Leszek Swirski authored
This is a reland of e1b93a4f which was a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Give up on using C++ bitfields, go back to having base::BitField and getters/setters. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67309}
-
Clemens Backes authored
If multiple compilation threads want to publish their generated code, they currently block on each other. This can cause multiple background threads to be blocked for several hundred milliseconds in the worst case. This CL changes this such that instead of blocking, the threads just put the code in a queue from where it is picked up by the thread that is currently publishing. Instead of blocking, the threads can then continue compiling more code already. This change might produce regressions, because there is now more TurboFan tier-up compilation happening while Liftoff code is being published. This might delay the completion of baseline compilation. It can also happen that we publish (more) TurboFan code before finishing baseline compilation, which would also regress compile scores. Let's see what the perf bots have to say about this CL. We might need to adapt certain things (like delaying TurboFan compilation until all Liftoff code finished), or we might just accept slight delays in Liftoff compilation, because tier-up will finish sooner after this CL, giving us peak performance earlier. R=ahaas@chromium.org Bug: v8:10330 Change-Id: I2f5c15810a0a9fc18461f9cbf4e436ab36aa559d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154200 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67308}
-
Andreas Haas authored
The existing code supports overlapping LiftoffRegisters in I64Binops by allocating a scratch register. Overlapping LiftoffRegisters means that the low register of one LiftoffRegister is the high register of another LiftoffRegister. When I64Binop is used in the implementation of atomic instructions, no scratch register is available, so overlapping LiftoffRegisters cannot be supported. As LiftoffRegisters are not supposed to overlap anyways, this CL removes this special handling. R=clemensb@chromium.org Bug: v8:10108 Change-Id: I9ce2143b0930688bc2e6dd56e151f47fba00ec87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151351 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67307}
-
Dan Elphick authored
The partial snapshot/serializer/deserializer are renamed to context *, while the partial snapshot cache is renamed to startup object cache in line with the read-only object cache (as this better reflects where it lives and what it does). To avoid a gap in the file history due to renaming both the files and identifiers simulataneously, this leaves all the partial-*.* files in place. They will be renamed in a follow-up CL. Bug: v8:10416 Change-Id: I5ef41cad751aaa24b35ee2b3c72bd0295832f2c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144115 Commit-Queue: Dan Elphick <delphick@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67306}
-
Seth Brenith authored
This is a reland of 80843eda Original change's description: > [torque] Allow storing to bitfield structs that are stored in Smis > > This change: > 1. Updates the Torque compiler to allow direct access to bitfields that > are packed within Smi values, which previously would have required a > separate untagging step, > 2. Updates JSRegExpStringIterator to represent its flags in Torque, > 3. Adds reduction cases in MachineOperatorReducer for when the input to > a branch or the left-hand side of a Word32Equals is based on a 64-bit > shift-and-mask operation which has been truncated to 32 bits, as is > the case in the code generated by step 1, and > 4. Adds a reduction case in MachineOperatorReducer to remove an extra > Word64And operation added by step 1. > > Bug: v8:7793 > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67290} Bug: v8:7793 Change-Id: I783b6ec080042fec0e922927f6675dede458a072 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67305}
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: Id0478287b2147ea231cd19dab6d08674b632b0e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159494 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67304}
-
Clemens Backes authored
When compiling modules with many functions, the list of regions in the {DisjointAllocationPool} can become quite large if the functions die in a random order (which they typically do, since the order of Liftoff compilation is different than the order to TurboFan compilation; which work stealing, both are nondeterministic). Iterating the list of regions in the {DisjointAllocationPool} was thus linear in the number of regions, which is linear in the number of functions of the module. Since we insert new regions one by one, overall runtime was quadratic. This CL fixes this by switching from a linked list to a std::set. Merging a new region is thus logarithmic instead of linear, and overall we are {n*log(n)} instead of {n^2}. Note: For {AllocateInRegion} we still need to linearly iterate all regions that overlap the requested region, but this has not shown to be a problem so far. R=ahaas@chromium.org Bug: v8:10432 Change-Id: I193e56c2abab782e386194fbe64dadfa250916f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154797 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67303}
-
Andreas Haas authored
With this CL we reuse the implementation of AtomicStore to implement AtomicBinops. The implementation is parametrised by an optional result Liftoff register, and by an operation that is applied on the value stored in the memory location. R=clemensb@chromium.org, v8-arm-ports@googlegroups.com Bug: v8:10108 Change-Id: I71ff5bf1632d860462d66b43c34515400eae2979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151349 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67302}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: Ib97bcc7afe516a014cd91128aa3c59f1b8b0b0af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151999 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67301}
-
Kim-Anh Tran authored
Bug: v8:1071760 Change-Id: Id2f75aef039574b918768fb323e1a8dbc999606f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159491Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#67300}
-
Yolanda Chen authored
This patch is to avoid spilling the phi at the loop header if there is a back-edge with an input for the phi that interferes with the phi's value, because in case that input gets spilled it might introduce a stack-to-stack move at the back-edge. Bug: chromium:1063831 Change-Id: Ie7129f10fb573cc799c588e6639b5ad486ea520d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152002 Commit-Queue: Yolanda Chen <yolanda.chen@intel.com> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67299}
-
Jakob Gruber authored
This is a reland of 5c4b8056 Original change's description: > [snapshot] Extract more files > > This moves: > > - ExternalReferenceEncoder to codegen/external-reference-encoder.h > - SerializerDeserializer to snapshot/serializer-deserializer.h > - Checksum() to snapshot/snapshot-utils.h > > serializer-common.h and .cc are removed. > > Tbr: clemensb@chromium.org,ulan@chromium.org > Bug: v8:10416 > Change-Id: I36a242dcc1ad8833374aa567f73e0d4a75632c58 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144118 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67281} Tbr: delphick@chromium.org,clemensb@chromium.org,ulan@chromium.org Bug: v8:10416 Change-Id: I6f6a1017435db185778ed931e1ddb13d8d5e920e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157384Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67298}
-
- 21 Apr, 2020 10 commits
-
-
Francis McCabe authored
This reverts commit 30c6bd45. Reason for revert: Breaks https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/30797? and https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4190 and https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/4190/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > [weakrefs] Ship WeakRef and FinalizationRegistry. > > I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/L04PqDk9eMU > Bug: v8:8179 > Change-Id: I52aaa62cdab981b802fa4a986d60421ef6efcfbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158371 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67295} TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org Change-Id: I22b7d91fcde9761c40d4ccaaccab24629cdb4249 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8179 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158924Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67297}
-
Bill Budge authored
- Reworks the builtins WasmTableGet and WasmTableSet to do the fast path, instead of generating this inline in wasm-compiler. Change-Id: I0a47c09d6f4f6d81c7b362f6f45e95b19e3edf86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135864 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67296}
-
Shu-yu Guo authored
I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/L04PqDk9eMU Bug: v8:8179 Change-Id: I52aaa62cdab981b802fa4a986d60421ef6efcfbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158371 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67295}
-
Shu-yu Guo authored
Use the InstallFunction helper to create the initial map and prototypes instead of manually doing so. WeakRef is currently creating an unused Map tied to JS_WEAK_REF_TYPE that would cause the various LogMaps cctests to fail when the feature ships. Bug: v8:8179 Change-Id: Ic1b35ebe5da722fa030af336099fff6153b4baed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158488 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67294}
-
Ben Noordhuis authored
Provide a stub `third_party_heap::Heap` implementation to work around linker erors with Visual Studio. cl.exe in debug mode seems to eliminate dead code not as aggressively as clang or gcc, resulting in references to `third_party_heap::Heap` remaining in unreachable code paths. Refs: https://github.com/bnoordhuis/v8-cmake/issues/10 Bug: v8:10427 Change-Id: I61fde11697adc663b182f60c132eda435a7f11bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159490 Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67293}
-
Bill Budge authored
- Adds builtins to convert between Int32/Float64 and JS Number. - WasmInt32ToHeapNumber (bypass SMI test) - WasmFloat64ToNumber - Adds builtins to convert between Tagged and Int32/Float64. - WasmTaggedNonSmiToInt32 (bypass SMI test) - WasmTaggedToFloat64 - Uses these builtins in Wasm import and export wrappers instead of generating the equivalent code inline. Results of running Wasm/import-export-wrappers.js Benchmark: https://docs.google.com/document/d/1QIB0xnqdJFRsOJKQYZ8DZgzWn4WysybgugbcO0sYcQA/edit?usp=sharing NOTE: CL will need to be rebased after linkage fix lands. Bug: v8:10070 Change-Id: Ib34507fcd18bdf80938b5707310a5a4f76cdec72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099445Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67292}
-
Francis McCabe authored
This reverts commit 80843eda. Reason for revert: Causes compilation failure on macs https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934? Original change's description: > [torque] Allow storing to bitfield structs that are stored in Smis > > This change: > 1. Updates the Torque compiler to allow direct access to bitfields that > are packed within Smi values, which previously would have required a > separate untagging step, > 2. Updates JSRegExpStringIterator to represent its flags in Torque, > 3. Adds reduction cases in MachineOperatorReducer for when the input to > a branch or the left-hand side of a Word32Equals is based on a 64-bit > shift-and-mask operation which has been truncated to 32 bits, as is > the case in the code generated by step 1, and > 4. Adds a reduction case in MachineOperatorReducer to remove an extra > Word64And operation added by step 1. > > Bug: v8:7793 > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67290} TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org Change-Id: Ifa683c92631291c9437438682b6efb2e12862682 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67291}
-
Seth Brenith authored
This change: 1. Updates the Torque compiler to allow direct access to bitfields that are packed within Smi values, which previously would have required a separate untagging step, 2. Updates JSRegExpStringIterator to represent its flags in Torque, 3. Adds reduction cases in MachineOperatorReducer for when the input to a branch or the left-hand side of a Word32Equals is based on a 64-bit shift-and-mask operation which has been truncated to 32 bits, as is the case in the code generated by step 1, and 4. Adds a reduction case in MachineOperatorReducer to remove an extra Word64And operation added by step 1. Bug: v8:7793 Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67290}
-
Mythri A authored
We give the optimized code another chance on soft deopts in TurboProp. If the deopt is happening on infrequently taken paths, then this will let us reuse the optimized code for the subsequent executions. If the soft deopts are happening multiple times on the same code, then we would discard the optimized code. The number of deopts we would wait is controlled by FLAG_reuse_opt_code_count. BUG=v8:10433 Change-Id: Iaadea4cffde7d7d55be4875c9586694dca64957c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093503 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67289}
-
Jakob Kummerow authored
Bug: v8:7748 Change-Id: I80265c7070dc7ec421bf53aa717a727c144b0699 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152844 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67288}
-