- 25 Oct, 2019 8 commits
-
-
Michael Starzinger authored
R=clemensb@chromium.org BUG=v8:9810 Change-Id: I4bfd667952cb933a131701c692cad18857df2244 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878711Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64562}
-
Leszek Swirski authored
Move around some methods to make LargeObjectSpace (mostly) thread-independent. Bug: chromium:1011762 Change-Id: I4cc512979a30fa21fd9cb3a90592761cbb01a303 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878709 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64561}
-
Leszek Swirski authored
Both LO_SPACE and NEW_LO_SPACE use the basic page management system of LargeObjectSpace, but implement different AllocateRaw methods (with the NEW_LO_SPACE version shadowing the LO_SPACE version). To clean this up, and allow other future LargeObjectSpace implementations (in particular, an off-thread variant), refactored the current LargeObjectSpace into a base class, and make both LargeObjectSpace (renamed to OldLargeObjectSpace) and NewLargeObjectSpace extend this class. Bug: chromium:1011762 Change-Id: I41b45b97f2611611dcfde677213131396df03a5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876824 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b293e4f..a193dcc Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/bf69ed0..a38631c Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ea98ebb..86244d6 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/aa07e59..662cbb8 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Iceb07046b9104a8f17303ed25b5d68713ec62216 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1880947Reviewed-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@{#64559}
-
Clemens Backes authored
This is a reland of bc8ad334. The CL was innocent, thus unmodified reland with TBR. Original change's description: > [wasm][debug] Report global scope also for compiled frames > > The global scope (containing global values and the memory) can be > produced from the instance alone, hence we can also report it for > compiled frames. > > R=mstarzinger@chromium.org, jgruber@chromium.org > > Bug: v8:9676 > Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64547} TBR=mstarzinger@chromium.org Bug: v8:9676 Change-Id: I2486a007156b7197d523f62ca3c30e29e7650b63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879929 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Michael Achenbach authored
NOTRY=true Bug: chromium:1018099 Change-Id: I14de41aac11220fedb58cda9bf5ce66424ff381c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879932Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#64557}
-
Michael Starzinger authored
This class used to describe unoptimized but compiled frames. All such frames are by now covered via the architecture-independent description in the {StandardFrameConstants} class (or one of its subclasses). R=clemensb@chromium.org BUG=v8:9810 Change-Id: I294cc6eec7d4a05e88e7aa336f1ebedfa0eb6e98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878708Reviewed-by:Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64556}
-
Liviu Rau authored
Basically we expose and put to shame the offending process R=tmrts@chromium.org Bug: v8:9855 Change-Id: I322e3f9db487b53e8cbfc8a5edd696fa8b480f84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878707 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#64555}
-
- 24 Oct, 2019 25 commits
-
-
Shu-yu Guo authored
This reverts commit 2599d3cc. Reason for revert: Test fails with OOM on Arm64 - N5X (https://ci.chromium.org/p/v8/builders/ci/V8%20Android%20Arm64%20-%20N5X/6514) and is racy on predictable builds (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20predictable/27044) Original change's description: > [wasm] Fix incorrect check for growing shared WebAssembly.memory > > Bug: chromium:1010272 > Change-Id: Ieff61089255ee088fad45f15a0f1a8f93eeec94b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869077 > Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64525} TBR=mstarzinger@chromium.org,gdeepti@chromium.org,ahaas@chromium.org Change-Id: I738a4021a80202c9b822815b922de31f95054fe6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1010272 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879513Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#64554}
-
Shu-yu Guo authored
This reverts commit 556f44c4. Reason for revert: Test fatally OOMs on ARM. https://ci.chromium.org/p/v8/builders/ci/V8%20Arm/12336 Original change's description: > [strings] Fix hash for exactly 512MB long strings > > Bug: chromium:1016237 > Change-Id: Idda1e44b5d578d1213aa54927ca68289bcdce8ac > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878487 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64552} TBR=jkummerow@chromium.org,ishell@chromium.org Change-Id: Ia942469346b0f11fcf853d21717fd127815f7fba No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1016237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879669Reviewed-by:
-
Jakob Kummerow authored
Bug: chromium:1016237 Change-Id: Idda1e44b5d578d1213aa54927ca68289bcdce8ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878487 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64552}
-
Michaël Zasso authored
On Windows with MSVC, compilation fails because it cannot find the GetIsolateForPtrCompr identifier. Change-Id: Ib03f5c5ef34e409242bbbe93ec83b7734012feb2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878712Reviewed-by:
-
Victor Gomes authored
The native context used an empty function scope info. This is inconsistent with the fact the native context has an extension slot, since the empty function scope info doesn't have the extension slot flag set. This CL creates a scope info dedicated for the native context with the flag set. Bug: v8:9744 Change-Id: I00459e9a0ca75dd7a0e2add5e9e61747d0635f39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876821 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
This reverts commit bc8ad334. Reason for revert: breaks ASAN: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20ASAN/33137 Original change's description: > [wasm][debug] Report global scope also for compiled frames > > The global scope (containing global values and the memory) can be > produced from the instance alone, hence we can also report it for > compiled frames. > > R=mstarzinger@chromium.org, jgruber@chromium.org > > Bug: v8:9676 > Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64547} TBR=mstarzinger@chromium.org,jgruber@chromium.org,clemensb@chromium.org Change-Id: I7a37723286315235f0c0a63728de58633a3b259e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9676 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878713Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#64549}
-
Mike Stanton authored
Add VirtualBoundFunction to the serializer which takes care of processing the result of Function.prototype.bind. Add cctest and an mjsunit test. Bug: v8:7790 Change-Id: Ic2b48d356cbe3b576eb22f58215cc886a8994e31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859625 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64548}
-
Clemens Backes authored
The global scope (containing global values and the memory) can be produced from the instance alone, hence we can also report it for compiled frames. R=mstarzinger@chromium.org, jgruber@chromium.org Bug: v8:9676 Change-Id: I20fbb74a98b00b128b6ed305b92fb56ad7dc7558 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876816Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64547}
-
Thibaud Michaud authored
Quoting from the spec, the expected behavior for validating unreachable code is that: A polymorphic stack cannot underflow, but instead generates Unknown types as needed. (https://webassembly.github.io/spec/core/appendix/algorithm.html) This CL changes the representation of the stack height in the interpreter's side table builder from unsigned to signed to prevent underflow, and makes some DCHECKs depend on code reachability. R=clemensb@chromium.org Bug: chromium:1017061 Change-Id: I4c999859019d6cefb76c1366ba0e98f199f7a0be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876813 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Michael Starzinger authored
Now that segmented code spaces are enabled for WebAssembly, tests that allocate a large number of modules should no longer flakily run OOM. R=clemensb@chromium.org TEST=mjsunit/wasm/asm-wasm-{i32,f64} BUG=v8:7899 Change-Id: Iab5d2c1b022cc1f6e44f132b14148c86f148cb54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876818Reviewed-by: -
Liviu Rau authored
Bug: v8:9898 Change-Id: I8bd453af9a14b04baec321b13e05918bc7abe093 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876812Reviewed-by:
-
Benedikt Meurer authored
This is an attempt to get a better understanding of the random crashes we get in chromium:893973. Bug: chromium:893973 Change-Id: Ia3b1e9910c9e48efb0bf3233050953f1117a2db9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876819 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64543}
-
Anna Henningsen authored
Add an `array_buffer_allocator_shared` field to the `Isolate::CreateParams` struct that allows embedders to share ownership of the ArrayBuffer::Allocator with V8, and which in particular means that when this method is used that the BackingStore deleter will not perform an use-after-free access to the Allocator under certain circumstances. For Background: tl;dr: This is necessary for Node.js to perform the transition to V8 7.9, because of the way that ArrayBuffer::Allocators and their lifetimes currently work there. In Node.js, each Worker thread has its own ArrayBuffer::Allocator. Changing that would currently be impractical, as each allocator depends on per-Isolate state. However, now that backing stores are managed globally and keep a pointer to the original ArrayBuffer::Allocator, this means that when transferring an ArrayBuffer (e.g. from one Worker to another through postMessage()), the original Allocator has to be kept alive until the ArrayBuffer no longer exists in the receiving Isolate (or until that Isolate is disposed). See [1] for an example Node.js test that fails with V8 7.9. This problem also existed for SharedArrayBuffers, where Node.js was broken by V8 earlier for the same reasons (see [2] for the bug report on that and [3] for the resolution in Node.js). For SharedArrayBuffers, we already had extensive tracking logic, so adding a shared_ptr to keep alive the ArrayBuffer::Allocator was not a significant amount of work. However, the mechanism for transferring non-shared ArrayBuffers is quite different, and it seems both easier for us and better for V8 from an API standpoint to keep the Allocator alive from where it is being referenced. By sharing memory with the custom deleter function/data pair, this comes at no memory overhead. [1]: https://github.com/nodejs/node/pull/30044 [2]: https://github.com/nodejs/node-v8/issues/115 [3]: https://github.com/nodejs/node/pull/29637 Bug: v8:9380 Change-Id: Ibc2c4fb6341b53653cbd637bd8cb3d4ac43809c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874347 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Igor Sheludko authored
The CL fixes the following builtins: Atomics.add Atomics.and Atomics.compareExchange Atomics.exchange Atomics.load Atomics.or Atomics.store Atomics.sub Atomics.xor Bug: v8:4153 Change-Id: Id6170fd093f6e2f9690838b4b789719ed2fc343c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876847 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64541}
-
Igor Sheludko authored
Bug: v8:6949 Change-Id: I01cb7180fbeea0a86e4fddc913311d6ece1aa5e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876065 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This makes sure that functions constructed via {WebAssembly.Function} can be properly stored in globals of type "funcref". For now it is not possible to call functions in such globals, but values can be loaded and stored. R=ahaas@chromium.org TEST=mjsunit/wasm/type-reflection-with-anyref BUG=v8:7742 Change-Id: I88ad1b5a57fd50e28723430803c528e674a94321 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876815Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64539}
-
Clemens Backes authored
This method should be reused for compiled frames, hence this CL moves it to the top-level in wasm-debug.cc, and makes it externally available via wasm-debug.h. R=mstarzinger@chromium.org Bug: v8:9676 Change-Id: If2fbcad1d0911efe4c2169e8a5bd85b598ac335f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876060Reviewed-by:
-
Ross McIlroy authored
This rearranges the TurboProp pipeline to avoid the need for a second schedule of the graph. To do this, it moves the final schedule creation before effect-control-linearization (which used a temporary schedule previously, and with TurboFan). It then enables the block updater in the graph assembler for effect control linearization and does select and memory lowering in a new ScheduledMachineLowering phase to maintain this existing schedule during these lowering passes. BUG=v8:9684 Change-Id: I6a7790b010f8b152dd01d85aa95ee5d4f99087a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847351 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
The Torque formatter script did a hack to put spaces arount the | of union types. This was broken when the inserted comment ended up on the end of a line. For this reason, and since it doesn't make sense to fight the Google-wide TypeScript style for union types, this CL reverts to not putting spaces around union types. Bug: v8:7793 Change-Id: Ic0acf9e1da82540432a8e21b58497a6a7d523b9c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871604 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
Clemens Backes authored
This extends the scope info test to also contain a compiled frame. Currently, no scope info is shown for this frame. This will change in the future, and the expected output will be extended accordingly. R=yangguo@chromium.org CC=mstarzinger@chromium.org Bug: v8:9676 Change-Id: Ie57c1fec5f7cbec737d40b18d091fc2d9a00f493 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876063 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This will allow us to reuse this method in other contexts. This CL also contains smaller refactorings that helped to move the code. E.g. the WASMVALUE_CTYPES macro (defined in value-type.h) replaces the WASM_CTYPES macro (from wasm-interpreter.cc). R=mstarzinger@chromium.org Bug: v8:9676 Change-Id: Id788f843af9a09eb940593afa1639f12b652c514 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876054 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This expands the existing mechanism for generic structs to also cover abstract types. This involves: - Moving the SpecializationKey from StructType to Type, so that it's also available to AbstractType. - Moving the generic parameters out of the StructDeclaration AST node and using the existing GenericDeclaration AST node for generic structs and abstract types too. - The GenericStructType declarable gets generalized to GenericType. This will be useful for defining a Weak<T> type for weak pointers. Bug: v8:7793 Change-Id: I183b3a038a143cf0ae5888150104c4a025fd736c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859623 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Mu Tao authored
This is the second porting of 0089006f The first not fully porting is da0ef75f Change-Id: Ia7e51a492df2fcab7da0cd8b2ff4d436c28563e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877794 Auto-Submit: Mu Tao <pamilty@gmail.com> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e9c43f1..b293e4f Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/9f6271e..bf69ed0 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/db1e79c..ea98ebb TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I8f3b4d7b302d63b7dc812cbba38e4ecd065d2e6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876524Reviewed-by:
-
Shu-yu Guo authored
Currently if the argument to matchAll has a null or undefined .flags property, the error message will read "String.prototype.matchAll called on null or undefined", which is very confusing. Drive-by fix: Remove the related and unused MethodInvokedOnNullOrUndefined error. Bug: v8:9895 Change-Id: I3644545282ac8d2156c7a51086e37a0ab7f97a78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874619 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
- 23 Oct, 2019 7 commits
-
-
Ng Zhi An authored
This adds avx for extractps, insertps, and cvtdq2ps. These require SSE4_1, so modified AvxHelper to take another template arg for sse4 operations, and open the proper cpu scope before calling this arg. Bug: v8:9561 Change-Id: Iad2be7ebab41b96f7eb74f4e2bd9776002e6a76c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874378 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#64529}
-
Ross McIlroy authored
Updates the EffectControlLinerizer to feed all nodes it processes through the GraphAssembler. This is required to enable the GraphAssembler to maintain the schedule for TurboProp, but also means we can avoid keeping track of the current effect and control nodes in the EffectControlLinearizer and use the GraphAssembler for that instead. Also modifies EffectControlLinearizer to avoid accessing the basic block while lowering nodes, since a basic block updating GraphAssembler could modify the current block. Once lowered, we finalizes GraphAssembler to provide the updated basic block for which the original control should be processed. BUG=v8:9684 Change-Id: Ibe7f396e15f8bebf35b9c50d56c245cbc92547f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1842453 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Mike Stanton authored
Specifically string, object, proxy & regexp. With this CL, the pattern is removed from all torque files. R=tebbi@chromium.org Change-Id: Ifcc1efda6053df8f02fc730825055f6cd5644e84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873691 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Frank Tang authored
This is a reland of 5d57f4e1 Breakage addressed by https://chromium-review.googlesource.com/c/chromium/src/+/1874491 Original change's description: > [Intl] Ship calendar and numberingSystem options > > Ship the "calendar" and "numberingSystem" options for > Intl.DateTimeFormat (both options) and Intl.NumberFormat (only the later > one) and support other calendar. Also consider the calendar while > choosing calendar pattern. > > I2L: http://shorturl.at/bgkAH > I2S: http://shorturl.at/nuKUV > > Flags: --harmony-intl-add-calendar-numbering-system > --harmony-intl-other-calendars > > API owner approvals: chrishtr@ yoav@yoav.ws bratell.d@gmail.com > > Plan to land into m80 tree and only merge after 10/17 m79 branch off. > > Bug: v8:9154, v8:9155, v8:9320 > Change-Id: Ifa209919a40db60465f99405f3620a3b73b10204 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1838436 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64437} Bug: v8:9154, v8:9155, v8:9320, chromium:1016909 Change-Id: Ie8eac6283042cb66fc4a98fd2230385c068fa759 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874089Reviewed-by:
-
Deepti Gandluri authored
Bug: chromium:1010272 Change-Id: Ieff61089255ee088fad45f15a0f1a8f93eeec94b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869077 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
-
Ng Zhi An authored
The immediate value was incorrect and-ed with 3. Also, for palignr, if the immediate is larger that 32 (for 128-bit) or 16 (for 64-bit), it produces a zero result. In the case of disasm, I don't think we need to do anything. Change-Id: I258fd16fbe57fa7e00ab306d0fbf1b1b73950566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876660Reviewed-by:
-
Irina Yatsenko authored
Crashkeys are static and non-refcounted, so when one thread clears a crashkey, it affects all other threads. This means, we cannot set them in parallel running jobs such as ScavengePage. This change moves the crashkey about heap collection up the stack into the main thread. Change-Id: I28f16eaadd9b122c06a68d1d4207f27319994509 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874384Reviewed-by:
-
