- 23 Apr, 2020 20 commits
-
-
Bill Budge authored
- Use a builtin for the fast path of Wasm RefFunc. - Simplify the runtime function by passing instance as first argument. Change-Id: I5f6993cae21a878cee21a391a25c4d574243058b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144533 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67346}
-
Frank Tang authored
Pick handful of failure cases from https://bugs.chromium.org/p/v8/issues/detail?id=10437 Mark the test fail The bug should be fixed by ICU67.1 and will be landed soon. Bug: v8:10437 Change-Id: Iac309dd48b2220da777c006c7a35fac24e454430 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161510 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67345}
-
Frank Tang authored
1. read and output into option after timeZoneName 2. Not output into resolvedOptions if dateStyle or timeStyle is presented. 3. Add unit test Spec: https://github.com/tc39/ecma402/pull/347 Bug: v8:10438 Change-Id: Ie7fecdb5b6dc83dc9a6dfd8ced26679a4051c833 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161509 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Adam Kallai authored
On Windows on ARM64 SIMD and Floating-point Registers aren't used, in case of variadic functions like printf [1]. So the arguments should be placed into general X0..X7 registers. [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions Bug: v8:10365 Change-Id: I67eb19be64df422e188edafc94200528c4e08482 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157374Reviewed-by:
Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67343}
-
Bill Budge authored
- Use the new builtin to convert f32 to Number, rather than changing to f64, then calling f64 to Number. Bug: v8:10070 Change-Id: I9a0660af8f5e517c2c6691d57d665b7e6316a51b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111714 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Ng Zhi An authored
In the reland, https://crrev.com/c/2157799, I accidentally left out the arm64 implementation. This adds it. R=clemensb@chromium.org Bug: v8:9909 Change-Id: I0e36f85402cd86ed7adaace43e7ec88f9aaad659 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161566Reviewed-by:
-
Leszek Swirski authored
We don't use StatsCounters anymore for heap work, and this particular counter causes issues for OffThreadSpace, as it can trigger a non-thread-safe counter callback. We could instead make this a thread-safe counter, but since it's unused we may as well just remove it entirely. Bug: chromium:1011762 Change-Id: I5af5ec5c408691ebfb762d87334ec4af54b1c0e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126914 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67340}
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I22351c7532e58ccd085f5934d1c59e0108c97cea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161390Reviewed-by:
-
Seth Brenith authored
This change allows Torque code to initialize bitfield structs, using the same syntax as struct initialization. It also moves the definition of the JSPromise flags to Torque as an example usage. Bug: v8:7793 Change-Id: I3d5e49aa22139ffb4b8ea9f308dd36a2d22b2c1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148176 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67338}
-
Leszek Swirski authored
Introduce an OffThreadTransferHandle (and OffThreadTransferMaybeHandle), which points to a piece of storage known to (and owned by) the OffThreadIsolate. On Publish, the OffThreadIsolate converts this storage stub from a raw pointer to an off-thread object into a main-thread Handle. This allows users of an OffThreadIsolate to not have to worry (as much) about the dance of saving raw object pointers before off-thread finishes and converting those to Handles before it off-thread isolate is published. Bug: chromium:1011762 Change-Id: I7ceb4ed85e770bd6e1867649188597bbcaedb32d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161066 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67337}
-
Maya Lekova authored
This CL handlifies the result of the Wait method to avoid possible pointer invalidation caused by a call to RunAtomicsWaitCallback. Bug: v8:9986 Change-Id: Iafb5d84ce372df3d75e408cfec73153b9f552493 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161069Reviewed-by:
Ben Smith <binji@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#67336}
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: Ie17013927cc9af002ba843eaa29e53f1a50df674 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162726Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67335}
-
Jakob Gruber authored
... by replacing manual memory management with unique_ptrs. Bug: v8:10416 Change-Id: Id3acb38192a5203bcb8c0f7eee774eacb934ef49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159492 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#67334}
-
Dan Elphick authored
Now that PartialSerializer/Deserializer/etc have been renamed to ContextSerializer/ContextDeserializer/etc, the files can now be renamed hopefully leaving the full history available in code search. Bug: v8:10416 Change-Id: I266c915f6d01a7e2913c4d34d9913fa551046dc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144061 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Make --stress-background-compile a V8 flag rather than a d8 flag, so that it also tests unittests/cctests. Now, with this flag, every top-level script compile (that fulfills a couple of restrictions) will be both main-thread and background-thread compiled, taking the result of the background compile. In the future, we'll probably want to verify that the two results are equivalent. One of the necessary changes to allow tests to pass was to introduce a concept of a "temporary" script (with a temporary script id), which doesn't get added to the script list. This is to avoid the main-thread compile part of the stress-test having a debugger-visible side-effect, e.g. in tests that enumerate scripts. We can't just create new ids for such scripts, as then script-id expectation files no longer match. Bug: chromium:1011762 Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10108 Change-Id: Ibb7e7e14e86957c6bf302fcfd3e1099d4f00c414 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154646 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Gus Caplan authored
https://tc39.es/proposal-logical-assignment/ Bug: v8:10372 Change-Id: I538d54af6b4b24d450d1398c74f76dd57fdb0147 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158119Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67330}
-
Leszek Swirski authored
Move the persistent compilation state and Isolate inputs (such as the allocator, shared AST constants, hash seed, logger, etc.) which survives across both parse and compile, out of ParseInfo and into a new UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState for per-thread state such as stack limit and RCS. In particular, this new state survives the ParseInfo being destructed, which means it is available after off-thread finalization. This allows a followup to access the PendingCompilationErrorHandler after finalization and report errors on merge. Bug: v8:10314 Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
Change-Id: I815979c232f0c781a76dd7954fbba9edabec7359 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152071Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#67328}
-
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 20 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:
-
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:
-
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:
-
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:
-
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:
-
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: -
Shu-yu Guo authored
Bug: chromium:1073263 Change-Id: I5c054e34242a91dafd6788814a39e97075d1035d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2160019Reviewed-by:
-
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:
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: I787c9bc9c998c873bf431df13eb3b92044cbc1e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157647Reviewed-by:
-
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:
-
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 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:
-
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:
-
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:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
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:
-
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 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:
-
