- 22 Jan, 2020 1 commit
-
-
Jakob Kummerow authored
The actual allocatable size still depends on the allocator; in particular Blink's ArrayBufferAllocator is currently limited to 2GB. WebAssembly memories are not affected by this change (i.e. still capped at 2GB as well). For 32-bit platforms, the limit remains at 2**30-1 (=max smi) elements. Bug: v8:4153 Change-Id: If0d6047dd4061028688d85a3dc0a2684dcca8693 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007495Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65924}
-
- 14 Nov, 2019 1 commit
-
-
Igor Sheludko authored
... that started failing on AIX where the allocation of a huge ArrayBuffer succeeds. Bug: v8:4153 Change-Id: I322c71e01edccb254a523f7f85817971b6c68242 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914561Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64960}
-
- 30 Apr, 2019 1 commit
-
-
Ben L. Titzer authored
R=binji@chromium.org Change-Id: I936d906be90c0c6d3b84b5ad4e8cb574ab8cd970 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585851 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#61135}
-
- 11 Dec, 2018 1 commit
-
-
Ben L. Titzer authored
This is purely a renaming change. The ES spec uses the term 'detach' for the process of removing the backing store of a typed array, while V8 uses the historical term 'neuter'. Update our internal implementation, including method names and flag names, to match the spec. Note that some error messages still use the term 'neuter' since error messages are asserted by some embedder tests, like layout tests. R=bmeurer@chromium.org, yangguo@chromium.org, mstarzinger@chromium.org, mlippautz@chromium.org BUG=chromium:913887 Change-Id: I62f1c3ac9ae67ba01d612a5221afa3d92deae272 Reviewed-on: https://chromium-review.googlesource.com/c/1370036 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#58149}
-
- 13 Nov, 2018 1 commit
-
-
peterwmwong authored
Previously, the following call sequence was always made when creating resulting subsetted TypedArray: 1) TFJ TypedArrayPrototypeSubArray 2) TFS TypedArrayConstructor 3) TFS CreateTypedArray This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is safe to use (IsPrototypeTypedArrayPrototype and !IsTypedArraySpeciesProtectorCellInvalid). Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement... BEFORE TypedArrays-SubarrayNoSpecies(Score): 1033530 TypedArrays-SubarrayNoSpecies(Score): 1018490 TypedArrays-SubarrayNoSpecies(Score): 1037030 AFTER TypedArrays-SubarrayNoSpecies(Score): 1439030 TypedArrays-SubarrayNoSpecies(Score): 1417540 TypedArrays-SubarrayNoSpecies(Score): 1405980 Bug: v8:7161 Change-Id: I356dace36570aa161ffe208a57a80e46714121a2 Reviewed-on: https://chromium-review.googlesource.com/c/1331154 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57458}
-
- 11 Jan, 2018 1 commit
-
-
Caitlin Potter authored
https://github.com/tc39/ecma262/pull/988 gained concensus during the september 2017 TC39 meetings. This moves the load of the "next" method to the very beginning of the iteration protocol, rather than during each iteration step. This impacts: - yield* - for-of loops - spread arguments - array spreads In the v8 implementation, this also affects async iteration versions of these things (the sole exception being the Async-From-Sync iterator, which requires a few more changes to work with this, likely done in a followup patch). This change introduces a new AST node, ResolvedProperty, which can be used as a callee by Call nodes to produce the same bytecode as Property calls, without observably re-loading the property. This is used in several AST-desugarings involving the iteration protocol. BUG=v8:6861, v8:5699 R=rmcilroy@chromium.org TBR=neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b Reviewed-on: https://chromium-review.googlesource.com/857593 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50518}
-
- 09 Jan, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit bf4cc9ee. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265 Original change's description: > [esnext] load `iterator.next` only once at beginning of iteration > > https://github.com/tc39/ecma262/pull/988 gained concensus during the > september 2017 TC39 meetings. This moves the load of the "next" method > to the very beginning of the iteration protocol, rather than during > each iteration step. > > This impacts: > > - yield* > - for-of loops > - spread arguments > - array spreads > > In the v8 implementation, this also affects async iteration versions of > these things (the sole exception being the Async-From-Sync iterator, > which requires a few more changes to work with this, likely done in a > followup patch). > > This change introduces a new AST node, ResolvedProperty, which can be used > as a callee by Call nodes to produce the same bytecode as Property calls, > without observably re-loading the property. This is used in several > AST-desugarings involving the iteration protocol. > > BUG=v8:6861, v8:5699 > R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b > Reviewed-on: https://chromium-review.googlesource.com/687997 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50452} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6861, v8:5699 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
-
Caitlin Potter authored
https://github.com/tc39/ecma262/pull/988 gained concensus during the september 2017 TC39 meetings. This moves the load of the "next" method to the very beginning of the iteration protocol, rather than during each iteration step. This impacts: - yield* - for-of loops - spread arguments - array spreads In the v8 implementation, this also affects async iteration versions of these things (the sole exception being the Async-From-Sync iterator, which requires a few more changes to work with this, likely done in a followup patch). This change introduces a new AST node, ResolvedProperty, which can be used as a callee by Call nodes to produce the same bytecode as Property calls, without observably re-loading the property. This is used in several AST-desugarings involving the iteration protocol. BUG=v8:6861, v8:5699 R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b Reviewed-on: https://chromium-review.googlesource.com/687997 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50452}
-
- 27 Nov, 2017 2 commits
-
-
Jakob Gruber authored
Pull most JSTypedArray source arguments onto the fast path. Same source & target elements-kinds simply call memmove. Other combinations call directly into C and reuse ElementsAccessor logic. Only overlapping source & target args with differing elements-kinds remain on the slow runtime path. Bug: v8:7123, v8:3590 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I80284b61478b0e3266b8f16bde8a56bd90f080b0 Reviewed-on: https://chromium-review.googlesource.com/788857 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49643}
-
jgruber authored
This adds a fast path that avoids the runtime transition for JSArray source arguments with {packed,holey} {smi,double} elements kinds. The fast path currently calls straight into C and copies there using elements accessor logic. Local tests show a 4x speedup when copying from 1-element JSArrays. As the source array becomes larger, the time spent copying elements begins to dominate. Bug: v8:3590 Change-Id: I05ebe54d7b255d0a76ad46ac11ce7cfd516b8ac8 Reviewed-on: https://chromium-review.googlesource.com/789010 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49634}
-
- 19 Oct, 2017 2 commits
-
-
Choongwoo Han authored
- Throw a TypeError exception if a given target argument is not a typed array before converting a given offset argument to an integer. - Add a testcase Bug: chromium:768775 Change-Id: Id132a0f154fcf930f211922fcbef6c66f9d6f285 Reviewed-on: https://chromium-review.googlesource.com/728120Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#48736}
-
Choongwoo Han authored
Replace GetElement and SetElement to Get and Set, and use CopyElements, which reduces 4x-13x overheads. Bug: chromium:768775 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I58534b30c2035195c5f4b8f2c04e7c459bdbebaa Reviewed-on: https://chromium-review.googlesource.com/720661Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#48723}
-
- 04 Sep, 2017 1 commit
-
-
Franziska Hinkelmann authored
When setting a typed array from an array like object, the length of the source can only be converted to a unit32 if it is not too large. Bug: v8:6704, chromium:761654 Change-Id: I8f89aa348093d8bd4d54aa16d6b5f255d3cb7adc Reviewed-on: https://chromium-review.googlesource.com/648976 Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#47798}
-
- 18 Aug, 2017 1 commit
-
-
Choongwoo Han authored
(source_length - 1) can be overflowed, and cause OOB access when source_length is zero. Thus, just do not operate setting if source_length is zero when starting TypedArraySetFromOverlapping. Bug: v8:6704 Change-Id: I5da60590c9a197eae96625a12720f6818b8c598a Reviewed-on: https://chromium-review.googlesource.com/620452 Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Reviewed-by: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#47430}
-
- 02 May, 2017 2 commits
-
-
Peter Marshall authored
The existing CHECK assumed that the source and destination could not have the same buffer, but they actually can as long as the data ranges do not overlap within the buffer. Change the check to look for this more relaxed condition instead. Moved the check outside of the memcpy case as well, given that it should also apply for the slower, element-by-element copy as well. Also use JSTypedArray::element_size() to get the element size instead of the helper on the FixedTypedArrayBase. This lets us change that helper back to private again. Bug: chromium:717022 Change-Id: I2eca1df1e87444c5db397e0b7cf686cefe67d29c Reviewed-on: https://chromium-review.googlesource.com/493147 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45035}
-
Peter Marshall authored
String inputs would end up in the fast-path, crashing because it expected an array type. Add the fast path explicitly when the source is a TypedArray, and let everything else fall back to the generic JS implementation. Bug: chromium:715971 Change-Id: Ieec28e93279047d403e00ed2676dc1eda193c033 Reviewed-on: https://chromium-review.googlesource.com/493226 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#45034}
-
- 13 Mar, 2017 1 commit
-
-
Peter Marshall authored
Part of the performance and refactoring work to move the TypedArray constructors into CSA. This CL moves ConstructByArrayBuffer from JS to CSA. BUG=v8:5977 Change-Id: I0a200e6b3f6261ea2372ea9c3d3ca98e313cf2c5 Reviewed-on: https://chromium-review.googlesource.com/451620 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#43747}
-
- 07 Mar, 2017 1 commit
-
-
Peter Marshall authored
Part of the performance and refactoring work to move the TypedArray constructors into CSA. This CL moves ConstructByLength from JS to CSA. There are still other callers to typed_array_initialize in typedarray.js, so we share the implementation using DoInitialize. In a later CL we can split apart DoInitialize once we have more TA constructors written in CSA, so that we can reuse specific parts more easily. BUG=v8:5977 Change-Id: Ia51e8363970e9a025a82933e56a7baaf82cb1eec Reviewed-on: https://chromium-review.googlesource.com/448220Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#43626}
-
- 03 Mar, 2017 1 commit
-
-
Peter Marshall authored
The callsite in ConstructByArrayBuffer could have a length that is above Smi range if the buffer had such a length. Check this before calling. Add a test too. BUG=v8:5977, chromium:698201 Change-Id: Ic22046a31607f1f85642c8caf7f5ed064edb3110 Reviewed-on: https://chromium-review.googlesource.com/449813 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#43589}
-
- 02 Mar, 2017 1 commit
-
-
Peter Marshall authored
Turbofan is a lot slower than Crankshaft at constructing TypedArrays, because we always go to the C++ builtin. Port the builtin to CSA to improve performance, and to clean up the implementation, which is split across multiple files and pieces at the moment. This CL increases the performance with --future to roughly the same as with crankshaft. BUG=v8:5977 Change-Id: Id0d91a4592de41a3a308846d79bd44a608931762 Reviewed-on: https://chromium-review.googlesource.com/448537Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#43548}
-
- 01 Mar, 2017 2 commits
-
-
Peter Marshall authored
This reverts commit b23b2c10. Reason for revert: Makes Linux debug bot sad Original change's description: > [builtins] Port TypedArrayInitialize to CodeStubAssembler. > > Turbofan is a lot slower than Crankshaft at constructing TypedArrays, > because we always go to the C++ builtin. Port the builtin to CSA > to improve performance, and to clean up the implementation, which is > split across multiple files and pieces at the moment. > > This CL increases the performance with --future to roughly the same > as with crankshaft. > > BUG=v8:5977 > > Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8 > Reviewed-on: https://chromium-review.googlesource.com/445717 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43518} TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5977 Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a Reviewed-on: https://chromium-review.googlesource.com/448558Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#43520}
-
Peter Marshall authored
Turbofan is a lot slower than Crankshaft at constructing TypedArrays, because we always go to the C++ builtin. Port the builtin to CSA to improve performance, and to clean up the implementation, which is split across multiple files and pieces at the moment. This CL increases the performance with --future to roughly the same as with crankshaft. BUG=v8:5977 Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8 Reviewed-on: https://chromium-review.googlesource.com/445717 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#43518}
-
- 05 Dec, 2016 1 commit
-
-
ynovikov authored
Reland of [typedarrays] remove invalid optimization in NAMEConstructor() (patchset #1 id:1 of https://codereview.chromium.org/2548583003/ ) Reason for revert: The bot was not affected by the revert. Speculation was wrong. Original issue's description: > Revert of [typedarrays] remove invalid optimization in NAMEConstructor() (patchset #1 id:1 of https://codereview.chromium.org/2544503002/ ) > > Reason for revert: > Speculative revert for causing timeouts on Win Debug gpu fyi bot > > Nothing else looks even remotely relevant in the list of changes. > Will reland if this doesn't fix the issues. > > BUG=670396 > > Original issue's description: > > [typedarrays] remove invalid optimization in NAMEConstructor() > > > > Before, we were treating objects with the builtin ArrayValues iterator > > method as array-like, where the iterator would iterate through to the > > full length of the object. > > > > This optimization was not sound, because it does not ensure that the > > next method hasn't been modified. Even if it hasn't been modified, > > it's entirely possible to be modified during iteration. Thus, this > > optimization has been removed due to its observability. > > > > BUG=v8:5699 > > R=littledan@chromium.org, cbruni@chromium.org > > > > Committed: https://crrev.com/77df8c67d9609ada3b7d79e8e6d33f198bbad5a1 > > Cr-Commit-Position: refs/heads/master@{#41394} > > TBR=cbruni@chromium.org,littledan@chromium.org,caitp@igalia.com > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=v8:5699 > > Committed: https://crrev.com/0ea4a542202d501c4e550474e89512532571f3a0 > Cr-Commit-Position: refs/heads/master@{#41461} TBR=cbruni@chromium.org,littledan@chromium.org,caitp@igalia.com,enne@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=670396 Review-Url: https://codereview.chromium.org/2553873002 Cr-Commit-Position: refs/heads/master@{#41504}
-
- 02 Dec, 2016 1 commit
-
-
enne authored
Revert of [typedarrays] remove invalid optimization in NAMEConstructor() (patchset #1 id:1 of https://codereview.chromium.org/2544503002/ ) Reason for revert: Speculative revert for causing timeouts on Win Debug gpu fyi bot Nothing else looks even remotely relevant in the list of changes. Will reland if this doesn't fix the issues. BUG=670396 Original issue's description: > [typedarrays] remove invalid optimization in NAMEConstructor() > > Before, we were treating objects with the builtin ArrayValues iterator > method as array-like, where the iterator would iterate through to the > full length of the object. > > This optimization was not sound, because it does not ensure that the > next method hasn't been modified. Even if it hasn't been modified, > it's entirely possible to be modified during iteration. Thus, this > optimization has been removed due to its observability. > > BUG=v8:5699 > R=littledan@chromium.org, cbruni@chromium.org > > Committed: https://crrev.com/77df8c67d9609ada3b7d79e8e6d33f198bbad5a1 > Cr-Commit-Position: refs/heads/master@{#41394} TBR=cbruni@chromium.org,littledan@chromium.org,caitp@igalia.com # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5699 Review-Url: https://codereview.chromium.org/2548583003 Cr-Commit-Position: refs/heads/master@{#41461}
-
- 30 Nov, 2016 1 commit
-
-
caitp authored
Before, we were treating objects with the builtin ArrayValues iterator method as array-like, where the iterator would iterate through to the full length of the object. This optimization was not sound, because it does not ensure that the next method hasn't been modified. Even if it hasn't been modified, it's entirely possible to be modified during iteration. Thus, this optimization has been removed due to its observability. BUG=v8:5699 R=littledan@chromium.org, cbruni@chromium.org Review-Url: https://codereview.chromium.org/2544503002 Cr-Commit-Position: refs/heads/master@{#41394}
-
- 17 Aug, 2016 1 commit
-
-
bakkot authored
Reland of Amends the TypedArray constructor to use the path for primitives for all (patchset #1 id:1 of https://codereview.chromium.org/2120763002/ ) Reason for revert: WebGL tests have been updated and rolled (at https://codereview.chromium.org/2227023002), so this should no longer fail outdated tests. Original issue's description: > Revert of Amends the TypedArray constructor to use the path for primitives for all (patchset #4 id:60001 of https://codereview.chromium.org/2096873002/ ) > > Reason for revert: > Speculative revert to unblock roll https://codereview.chromium.org/2114113002/ > > Original issue's description: > > Amends the TypedArray constructor to use the path for primitives for all > > types of primitives, not just undefined, booleans, numbers, and strings. > > (The missing cases were null and Symbol.) This is required by the > > specification, and there are test262 tests which we were failing due to > > this bug. > > > > BUG=v8:5124 > > > > Committed: https://crrev.com/f788bd9cce19815cba746e47bb65abfe25c16208 > > Committed: https://crrev.com/f772c22cd1c492aa0235a8e6012d0386146d2eb2 > > Cr-Original-Commit-Position: refs/heads/master@{#37234} > > Cr-Commit-Position: refs/heads/master@{#37407} > > TBR=littledan@chromium.org,bakkot@google.com > NOTREECHECKS=true > BUG=v8:5124 > > Committed: https://crrev.com/9c0aef52fa672db856ebfac7f4bdcd7d7b103663 > Cr-Commit-Position: refs/heads/master@{#37487} TBR=littledan@chromium.org,hablich@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5124 Review-Url: https://codereview.chromium.org/2255543002 Cr-Commit-Position: refs/heads/master@{#38691}
-
- 02 Jul, 2016 1 commit
-
-
hablich authored
Revert of Amends the TypedArray constructor to use the path for primitives for all (patchset #4 id:60001 of https://codereview.chromium.org/2096873002/ ) Reason for revert: Speculative revert to unblock roll https://codereview.chromium.org/2114113002/ Original issue's description: > Amends the TypedArray constructor to use the path for primitives for all > types of primitives, not just undefined, booleans, numbers, and strings. > (The missing cases were null and Symbol.) This is required by the > specification, and there are test262 tests which we were failing due to > this bug. > > BUG=v8:5124 > > Committed: https://crrev.com/f788bd9cce19815cba746e47bb65abfe25c16208 > Committed: https://crrev.com/f772c22cd1c492aa0235a8e6012d0386146d2eb2 > Cr-Original-Commit-Position: refs/heads/master@{#37234} > Cr-Commit-Position: refs/heads/master@{#37407} TBR=littledan@chromium.org,bakkot@google.com NOTREECHECKS=true BUG=v8:5124 Review-Url: https://codereview.chromium.org/2120763002 Cr-Commit-Position: refs/heads/master@{#37487}
-
- 29 Jun, 2016 1 commit
-
-
bakkot authored
types of primitives, not just undefined, booleans, numbers, and strings. (The missing cases were null and Symbol.) This is required by the specification, and there are test262 tests which we were failing due to this bug. BUG=v8:5124 Committed: https://crrev.com/f788bd9cce19815cba746e47bb65abfe25c16208 Review-Url: https://codereview.chromium.org/2096873002 Cr-Original-Commit-Position: refs/heads/master@{#37234} Cr-Commit-Position: refs/heads/master@{#37407}
-
- 24 Jun, 2016 2 commits
-
-
machenbach authored
Revert of Amends the TypedArray constructor to use the path for primitives for all (patchset #3 id:40001 of https://codereview.chromium.org/2096873002/ ) Reason for revert: [Sheriff] Breaks layout tests. Please rebase upstream if intended: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7691 Original issue's description: > Amends the TypedArray constructor to use the path for primitives for all > types of primitives, not just undefined, booleans, numbers, and strings. > (The missing cases were null and Symbol.) This is required by the > specification, and there are test262 tests which we were failing due to > this bug. > > BUG=v8:5124 > > Committed: https://crrev.com/f788bd9cce19815cba746e47bb65abfe25c16208 > Cr-Commit-Position: refs/heads/master@{#37234} TBR=littledan@chromium.org,bakkot@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5124 Review-Url: https://codereview.chromium.org/2091693004 Cr-Commit-Position: refs/heads/master@{#37236}
-
bakkot authored
types of primitives, not just undefined, booleans, numbers, and strings. (The missing cases were null and Symbol.) This is required by the specification, and there are test262 tests which we were failing due to this bug. BUG=v8:5124 Review-Url: https://codereview.chromium.org/2096873002 Cr-Commit-Position: refs/heads/master@{#37234}
-
- 11 Mar, 2016 1 commit
-
-
adamk authored
ES2015 Object.prototype.toString semantics were enabled in version 4.9, which has been in stable Chrome for nearly two weeks at this point. R=littledan@chromium.org Review URL: https://codereview.chromium.org/1784033002 Cr-Commit-Position: refs/heads/master@{#34732}
-
- 19 Feb, 2016 1 commit
-
-
bmeurer authored
The DataView constructor calls into C++ anyway, and is easier to deal with this way, especially since we don't have the half initialized object floating through JavaScript. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1712163002 Cr-Commit-Position: refs/heads/master@{#34145}
-
- 26 Jan, 2016 1 commit
-
-
littledan authored
Functions like DataView.prototype.getUint8 should have length 1, and DataView.prototype.setUint8 should have length 2, as their endianness arguments are optional. Additionally, TypedArray.prototype.set.length should be 2. This follows the ES2015 specification, and a new test262 test tests for it. This patch fixes the functions' lengths. R=adamk Review URL: https://codereview.chromium.org/1636953003 Cr-Commit-Position: refs/heads/master@{#33531}
-
- 30 Dec, 2015 1 commit
-
-
littledan authored
Reland of Use ES2015-style TypedArray prototype chain (patchset #1 id:1 of https://codereview.chromium.org/1554523002/ ) Reason for revert: Should be fixed again with this Blink change to add NeedsManualRebaseline Original issue's description: > Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ ) > > Reason for revert: > [Sheriff] Changes layout tests. Please fix upstream first if intended. > > https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689 > > Original issue's description: > > Use ES2015-style TypedArray prototype chain > > > > This patch switches TypedArrays to use the prototype chain described > > in the ES2015 specification, which adds a %TypedArray% superclass above > > all individual TypedArray types. Most methods are defined on the > > superclass rather than the subclasses. > > > > In order to prevent a performance regression, a few methods are > > marked as inline. Inlining might prevent code which was previously > > monomorphic from becoming polymorphic, and it was specifically > > applied in places where methods became more polymorphic than before. > > Tests with realistic workloads would be nice to do before this > > ships in stable. > > > > This patch does not bring TypedArrays up to full spec compliance. In > > particular, @@species is not yet supported. > > > > R=cbruni > > BUG=v8:4085 > > LOG=Y > > > > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7 > > Cr-Commit-Position: refs/heads/master@{#33050} > > TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:4085 > > Committed: https://crrev.com/28b55ffd1e32e09aaf42b8bbb407944d4808e07c > Cr-Commit-Position: refs/heads/master@{#33053} TBR=caitpotter88@gmail.com,cbruni@chromium.org,machenbach@chromium.org BUG=v8:4085 LOG=Y CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1558663002 Cr-Commit-Position: refs/heads/master@{#33067}
-
- 29 Dec, 2015 1 commit
-
-
machenbach authored
Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ ) Reason for revert: [Sheriff] Changes layout tests. Please fix upstream first if intended. https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689 Original issue's description: > Use ES2015-style TypedArray prototype chain > > This patch switches TypedArrays to use the prototype chain described > in the ES2015 specification, which adds a %TypedArray% superclass above > all individual TypedArray types. Most methods are defined on the > superclass rather than the subclasses. > > In order to prevent a performance regression, a few methods are > marked as inline. Inlining might prevent code which was previously > monomorphic from becoming polymorphic, and it was specifically > applied in places where methods became more polymorphic than before. > Tests with realistic workloads would be nice to do before this > ships in stable. > > This patch does not bring TypedArrays up to full spec compliance. In > particular, @@species is not yet supported. > > R=cbruni > BUG=v8:4085 > LOG=Y > > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7 > Cr-Commit-Position: refs/heads/master@{#33050} TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4085 Review URL: https://codereview.chromium.org/1554523002 Cr-Commit-Position: refs/heads/master@{#33053}
-
- 28 Dec, 2015 1 commit
-
-
littledan authored
This patch switches TypedArrays to use the prototype chain described in the ES2015 specification, which adds a %TypedArray% superclass above all individual TypedArray types. Most methods are defined on the superclass rather than the subclasses. In order to prevent a performance regression, a few methods are marked as inline. Inlining might prevent code which was previously monomorphic from becoming polymorphic, and it was specifically applied in places where methods became more polymorphic than before. Tests with realistic workloads would be nice to do before this ships in stable. This patch does not bring TypedArrays up to full spec compliance. In particular, @@species is not yet supported. R=cbruni BUG=v8:4085 LOG=Y Review URL: https://codereview.chromium.org/1541233002 Cr-Commit-Position: refs/heads/master@{#33050}
-
- 04 Dec, 2015 1 commit
-
-
machenbach authored
Revert of [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors. (patchset #2 id:20001 of https://codereview.chromium.org/1500543002/ ) Reason for revert: Blocks the roll: https://codereview.chromium.org/1497763004/ Original issue's description: > [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors. > > The ArrayBuffer and SharedArrayBuffer constructors should raise an > exception when called with no arguments or undefined length. Also > unified the ArrayBuffer and SharedArrayBuffer implementations as C++ > builtins, and removed some (now) obsolete runtime entries. > > R=yangguo@chromium.org > > Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e > Cr-Commit-Position: refs/heads/master@{#32590} TBR=yangguo@chromium.org,cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1501673002 Cr-Commit-Position: refs/heads/master@{#32606}
-
- 03 Dec, 2015 1 commit
-
-
bmeurer authored
The ArrayBuffer and SharedArrayBuffer constructors should raise an exception when called with no arguments or undefined length. Also unified the ArrayBuffer and SharedArrayBuffer implementations as C++ builtins, and removed some (now) obsolete runtime entries. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1500543002 Cr-Commit-Position: refs/heads/master@{#32590}
-
- 19 Oct, 2015 1 commit
-
-
hablich authored
Should already work according to issue. BUG=chromium:424619 LOG=N R=adamk@chromium.org, littledan@chromium.org Review URL: https://codereview.chromium.org/1413913002 Cr-Commit-Position: refs/heads/master@{#31379}
-
- 17 Jul, 2015 1 commit
-
-
littledan authored
- Test that TypedArray properties cannot be set in strict mode Properties like %TypedArray%.prototype.length have a getter and no setter. This test verifies that property, which was apparently not true in the past or had no test ensuring throwing in this case. - Test that TypedArray integer indexed properties (array elements) are not configurable Both of these have passed for some time, but there are open bugs against them and apparently no tests verifying that they are fixed. BUG=v8:3048, v8:3799 LOG=N R=adamk Review URL: https://codereview.chromium.org/1232843005 Cr-Commit-Position: refs/heads/master@{#29717}
-