- 22 Jun, 2017 2 commits
-
-
Ulan Degenbaev authored
This patch also adds handling of NativeContext and BytecodeArray. BUG=chromium:694255 Change-Id: I6d4b2db03ece7346200853bd0b80daf65672787f Reviewed-on: https://chromium-review.googlesource.com/543237 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46139}
-
Daniel Ehrenberg authored
In edge cases such as the following, sloppy-mode block-scoped function hoisting is expected to occur: eval(` with({a: 1}) { function a() {} } `) In this case, there should be the equivalent of a var declaration outside of the eval, which gets set to the value of the local function a when the body of the with is executed. Previously, the way that var declarations are hoisted out of eval meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL assignment. However, such a lookup mode meant that the object in the with scope received the assignment! This patch fixes that error by marking the assignments produced by the sloppy mode block scoped function hoisting desugaring so as to generate a different runtime call which skips with scopes. Bug: chromium:720247, v8:5135 Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748 Reviewed-on: https://chromium-review.googlesource.com/529230 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46116}
-
- 19 Jun, 2017 1 commit
-
-
Peter Marshall authored
We only need to use this for certain Intrinsics defined in the spec. This CL removes unnecessary uses. Bug: v8:6474 Change-Id: I13a9f0c57d877dd65a883a38f9683d55623030d3 Reviewed-on: https://chromium-review.googlesource.com/529224 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#46012}
-
- 14 Jun, 2017 2 commits
-
-
Alexey Kozyatinskiy authored
Context::Lookup method should support Module variables. Bug: chromium:717670 Change-Id: I58d3448b9048c7f9dd7ab8b720803b3503cf91ae Reviewed-on: https://chromium-review.googlesource.com/519389 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45950}
-
Caitlin Potter authored
Simplifies the implementation of IteratorClose in IteratorBuiltinsAssembler, and makes clear that it is only invoked when an exception occurs. Adds exception handling support to GetIterator, IteratorStep, and IteratorCloseOnException. Moves the Promise.all resolveElement closure and it's caller to builtins-promise-gen.cc. Instead of creating an internal array (and copying its elements into a result array), a single JSArray is allocated, and appended with BuildAppendJSArray(), falling back to %CreateDataProperty(), and elements are updated in the resolve closure the same way. This should always be unobservable. This CL increases the size of snapshot_blob.bin on an x64.release build by 8.51kb BUG=v8:5343 R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org, hpayer@chromium.org, tebbi@chromium.org Change-Id: I29c4a529154ef49ad65555ce6ddc2c5b7c9de6b3 Reviewed-on: https://chromium-review.googlesource.com/508473 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45946}
-
- 13 Jun, 2017 1 commit
-
-
Ben Smith authored
It is only attached to the global object if the --harmony-sharedarraybuffer flag is enabled, but this allows more objects to be added to the snapshot which seems to reduce the amount of heap memory used per context. Bug: chromium:724053 Change-Id: I5d1115a0e3ed9abf41cb3ab80d19d622cbef7b93 Reviewed-on: https://chromium-review.googlesource.com/534594Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#45930}
-
- 12 Jun, 2017 1 commit
-
-
Igor Sheludko authored
... by reading the |map_index| value from the SharedFunctionInfo's |compiler_hints| field directly. Bug: v8:6459 Change-Id: I32c4c903b16fa9f7e7da755667dadef7fadfc5e0 Reviewed-on: https://chromium-review.googlesource.com/531024 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#45871}
-
- 15 May, 2017 2 commits
-
-
Clemens Hammacher authored
This reverts commit 7ef1df85. Reason for revert: Breaks inspector/debugger/get-possible-breakpoints-restrict-to-function: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13191/steps/Check/logs/get-possible-breakpoi.. Original change's description: > [builtins] port Promise.all to CSA > > Introduces CodeStubAssembler helpers for common Iterator operations > (GetIterator, IteratorStep, IteratorClose). > > Moves the Promise.all resolveElement closure and it's caller to > builtins-promise-gen.cc. > > Instead of creating an internal array (and copying its elements into a result > array), a single JSArray is allocated, and appended with BuildAppendJSArray(), > falling back to %CreateDataProperty(), and elements are updated in the resolve > closure the same way. This should always be unobservable. > > This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb > > BUG=v8:5343 > R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org > > Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418 > Reviewed-on: https://chromium-review.googlesource.com/497974 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45306} TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,ishell@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5343 Change-Id: I831738003643561fa628266af2bcebbb18000e55 Reviewed-on: https://chromium-review.googlesource.com/506014Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45313}
-
Caitlin Potter authored
Introduces CodeStubAssembler helpers for common Iterator operations (GetIterator, IteratorStep, IteratorClose). Moves the Promise.all resolveElement closure and it's caller to builtins-promise-gen.cc. Instead of creating an internal array (and copying its elements into a result array), a single JSArray is allocated, and appended with BuildAppendJSArray(), falling back to %CreateDataProperty(), and elements are updated in the resolve closure the same way. This should always be unobservable. This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb BUG=v8:5343 R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418 Reviewed-on: https://chromium-review.googlesource.com/497974 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45306}
-
- 10 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
-
- 08 May, 2017 1 commit
-
-
Ross McIlroy authored
This reverts commit 662aa425. Reason for revert: Crashing on Canary BUG=chromium:718891 Original change's description: > Reland: [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > TBR=yangguo@chromium.org,ulan@chromium.org > > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 > Reviewed-on: https://chromium-review.googlesource.com/494487 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45084} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6246 Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82 Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45174}
-
- 04 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45084}
-
- 02 May, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit c5ad9c6d. Reason for revert: Fails on gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661 Original change's description: > [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > > Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 > Reviewed-on: https://chromium-review.googlesource.com/476891 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45022} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6246 Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619 Reviewed-on: https://chromium-review.googlesource.com/493287Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45027}
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 Reviewed-on: https://chromium-review.googlesource.com/476891 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45022}
-
- 27 Apr, 2017 1 commit
-
-
cbruni authored
With this CL we reduce the difference between directly using a null prototype in a literal or using Object.create(null). - The EmitFastCloneShallowObject builtin now supports cloning slow object boilerplates. - Unified behavior to find the matching Map and instantiating it for Object.create(null) and literals with a null prototype. - Cleanup of literal type parameter of CompileTimeValue, now in sync with ObjectLiteral flags. Review-Url: https://codereview.chromium.org/2445333002 Cr-Commit-Position: refs/heads/master@{#44941}
-
- 25 Apr, 2017 1 commit
-
-
Peter Marshall authored
This CL is purely refactoring, no behavior changes. Remove InitializeBasedOnLength and combine it with a new Stub-ified TypedArrayInitialize which now allocates the buffer in both the on-heap and off-heap cases. Add TypedArrayInitializeWithBuffer because this was essentially a special case that didn't share much logic with Initialize. Factor out the common pieces into SetupTypedArray and AttachBuffer. We can also always pass in the elementsSize, so there is no need to calculate this again. LoadMapAndElementsSize is changed to LoadMapForType. This reduces code size by ~8k. Bug: chromium:711275,chromium:701768 Change-Id: I6ad8701e9c72f53bfd9484725fb82055be568c25 Reviewed-on: https://chromium-review.googlesource.com/483481 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#44850}
-
- 24 Apr, 2017 1 commit
-
-
Caitlin Potter authored
The AsyncGeneratorYield builtin just invoked the AsyncGeneratorResolve() stub anyways, so this removes the middle-man. Really minor refactoring, but clears out a bit of snapshot size and another context index. BUG=v8:5855 R=rmcilroy@chromium.org, bmeurer@chromium.org Change-Id: I3385a5c5412e8d58493601874c2ad6b60e613012 Reviewed-on: https://chromium-review.googlesource.com/471913 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44820}
-
- 19 Apr, 2017 1 commit
-
-
Peter Marshall authored
This includes a fastpath in the ElementsAccessor for the source array being a JSArray with FastSmi or FastDouble packed kinds. This is probably a pretty common usage, where an array is passed in as a way of initializing the TypedArray at creation (as there is not other syntax to do this). e.g. new Float64Array([1.0, 1.0, 1.0]) for some sort of vector application. BUG= v8:5977 Change-Id: Ice4ad9fc29f56b1c4b0b30736a1330efdc289003 Reviewed-on: https://chromium-review.googlesource.com/465126Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44722}
-
- 13 Apr, 2017 1 commit
-
-
Caitlin Potter authored
https://github.com/tc39/proposal-async-iteration/commit/e3246ad69cc6f83b34bdd3451c3c6abce37fd1f3 removed some redundancies in yield and yield*. In particular: - AsyncGeneratorRawYield becomes unnecessary, and is deleted in this CL - Parser::RewriteYieldStar() is updated to perform the IteratorValue() algorithm as appropriate BUG=v8:6187, v8:5855 R=rmcilroy@chromium.org, adamk@chromium.org, littledan@chromium.org, vogelheim@chromium.org Change-Id: I05e8429b9cbd4531c330ee53a05656b90162064c Reviewed-on: https://chromium-review.googlesource.com/471806Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#44649}
-
- 12 Apr, 2017 2 commits
-
-
Marja Hölttä authored
The biggest problem is isolate.h (this CL doesn't solve that yet). BUG=v8:5294 Change-Id: I56b32109f501c48facd99cd12ca6c8f427e188a9 Reviewed-on: https://chromium-review.googlesource.com/471487Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44613}
-
yangguo authored
We used to reserve the 0-th embedder data field for the debug context id. This is no longer necessary since the inspector has migrated to be part of V8. This makes the API a bit simpler. R=clemensh@chromium.org, jochen@chromium.org, kozyatinskiy@chromium.org BUG=v8:5530 Review-Url: https://codereview.chromium.org/2806303002 Cr-Commit-Position: refs/heads/master@{#44607}
-
- 10 Apr, 2017 1 commit
-
-
Peter Marshall authored
The spec requires that we use IterableToList, which we skipped for some arrays as an optimization. We can't skip this for arrays with objects though, because the objects may mutate the array during the copying step via valueOf side effects. Also clean up the implementation to use a runtime function rather than a builtin as the helper. Also reverses the result of the helper because I think it is a bit more intuitive that way. Bug: v8:6224 Change-Id: I9199491abede4479785df6d9068331bc2d6e9c5e Reviewed-on: https://chromium-review.googlesource.com/471986Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44507}
-
- 06 Apr, 2017 1 commit
-
-
Peter Marshall authored
Currently we initialize the allocated buffer to be full of 0s, which adds significant overhead. TypedArrayConstructByArrayLike will always either fully initialize the buffer, or throw an exception, in which case the buffer will not be leaked to user code. The length of the new TypedArray (and thus the buffer) is derived from the length of the source Array/TypedArray, so we know that we will always set every byte of the new buffer, or throw trying. Bug:v8:5977 Change-Id: I8ceaa883cfad85f8708a5bdaada3ce463d97e007 Reviewed-on: https://chromium-review.googlesource.com/469348Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44447}
-
- 31 Mar, 2017 2 commits
-
-
Peter Marshall authored
This CL uses the same logic as spread calls to check whether the iteration over an array would produce different results to simply accessing the backing store directly. Skipping the full iteration protocol for normal arrays gives us a ~10x speedup on the construct-typedarray benchmark. BUG=v8:5977,v8:5699,v8:4782,chromium:698173 Change-Id: Ib878d39691e99b739afef0dd05a6a6efc5b6b5d4 Reviewed-on: https://chromium-review.googlesource.com/463367Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44304}
-
Peter Marshall authored
The last CL https://chromium-review.googlesource.com/c/456707/ caused some pretty heavy performance regressions. After experimenting, it seems the easiest and most straight-forward way to copy the elements into the new typed array is to do it in JS. Adds a fast path for typed arrays, where the source typed array has the same elements kind, in which case we can just copy the backing store using memcpy. This CL also removes regression test 319120 which is from a pwn2own vulnerability. The old code path enforced a maximum byte_length that was too low, which this change removes. The length property of the typed array must be a Smi, but the byte_length, which can be up to 8x larger than length for a Float64Array, can be a heap number. We can also re-use some of the logic from ConstructByLength when deciding whether to allocate the buffer on- or off-heap, so that is factored out into InitializeBasedOnLength. We can also re-use the DoInitialize helper instead of calling into the runtime, meaning we can remove InitializeFromArrayLike. BUG=v8:5977,chromium:705503,chromium:705394 Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755 Reviewed-on: https://chromium-review.googlesource.com/459621Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44301}
-
- 29 Mar, 2017 1 commit
-
-
Caitlin Potter authored
- Introduce new struct AsyncGeneratorRequest, which holds information pertinent to resuming execution of an AsyncGenerator, such as the Promise associated with the async generator request. It is intended to be used as a singly linked list, and holds a pointer to the next item in te queue. - Introduce JSAsyncGeneratorObject (subclass of JSGeneratorObject), which includes several new internal fields (`queue` which contains a singly linked list of AsyncGeneratorRequest objects, and `await_input` which contains the sent value from an Await expression (This is necessary to prevent function.sent (used by yield*) from having the sent value observably overwritten during execution). - Modify SuspendGenerator to accept a set of Flags, which indicate whether the suspend is for a Yield or Await, and whether it takes place on an async generator or ES6 generator. - Introduce interpreter intrinsics and TF intrinsic lowering for accessing the await input of an async generator - Modify the JSGeneratorStore operator to understand whether or not it's suspending for a normal yield, or an AsyncGenerator Await. This ensures appropriate registers are stored. - Add versions of ResumeGeneratorTrampoline which store the input value in a different field depending on wether it's an AsyncGenerator Await resume, or an ordinary resume. Also modifies whether debug code will assert that the generator object is a JSGeneratorObject or a JSAsyncGeneratorObject depending on the resume type. BUG=v8:5855 R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org, littledan@chromium.org, neis@chromium.org TBR=marja@chromium.org Change-Id: I9d58df1d344465fc937fe7eed322424204497187 Reviewed-on: https://chromium-review.googlesource.com/446961 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#44240}
-
- 24 Mar, 2017 1 commit
-
-
Peter Marshall authored
This helper is used directly when constructing from an object with a length, as well as by ConstructByIterable and ByTypedArray. BUG=v8:5977 Change-Id: I18a4829c2a22a6099cf3b0824ea1f698bfbf1917 Reviewed-on: https://chromium-review.googlesource.com/456707Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Franziska Hinkelmann <franzih@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44116}
-
- 22 Mar, 2017 1 commit
-
-
Caitlin Potter authored
Just the front-end side of https://chromium-review.googlesource.com/c/446961/. Adds support for parsing AsyncGeneratorExpression, AsyncGeneratorDeclaration, and AsyncGeneratorMethod, as well as parser tests. BUG=v8:5855 R=neis@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I70e1a9681f22573f29292eacb4b9f57f9a38e2b2 Reviewed-on: https://chromium-review.googlesource.com/447117Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#44040}
-
- 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}
-
- 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}
-
- 24 Feb, 2017 1 commit
-
-
caitp authored
Introduce a new Object to allow GetIterator("async") to function when the iterable does not have a Symbol.asyncIterator method. This patch has been split out from https://codereview.chromium.org/2622833002/ and incorporates test cases. BUG=v8:5855, v8:4483 R=jgruber@chromium.org, rmcilroy@chromium.org, neis@chromium.org TBR=hpayer@chromium.org, bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2645313003 Cr-Commit-Position: refs/heads/master@{#43419}
-
- 17 Feb, 2017 1 commit
-
-
gsathya authored
Adds five new TF builtins for the spec defined functions/closures. This follows mechanism similar to promise resolving functions approach where we store the closure variables in a custom context. Adds a new --harmony-promise-finally flag. BUG=v8:5967 Review-Url: https://codereview.chromium.org/2695753002 Cr-Commit-Position: refs/heads/master@{#43294}
-
- 15 Feb, 2017 2 commits
-
-
caitp authored
Some of these functions are invoked by BytecodeGenerator due to parser desugarings, and moving the context indices cause BytecodeExpectationsPrinter to render them as something useful/meaningful. BUG= R=jgruber@chromium.org, adamk@chromium.org Review-Url: https://codereview.chromium.org/2695323002 Cr-Commit-Position: refs/heads/master@{#43225}
-
littledan authored
These experimental natives previously only installed functions to the appropriate parent. In this patch, the exports container is retained so that the bootstrapper may install the functions instead. This change is intended to reduce startup time. SharedArrayBuffer retains some experimental natives exported from JS; this may be addressed in a follow-on patch. The patch includes some minor cleanup of the bootstrap process by removing "experimental exports", which was unused. R=yangguo@chromium.org BUG=v8:5880 CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng Review-Url: https://codereview.chromium.org/2683083003 Cr-Commit-Position: refs/heads/master@{#43221}
-
- 14 Feb, 2017 1 commit
-
-
bbudge authored
LOG=Y BUG=v8:4124,v8:5948 R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org Review-Url: https://codereview.chromium.org/2684313003 Cr-Original-Original-Commit-Position: refs/heads/master@{#43162} Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c Review-Url: https://codereview.chromium.org/2684313003 Cr-Original-Commit-Position: refs/heads/master@{#43169} Committed: https://chromium.googlesource.com/v8/v8/+/a9b59a11f1bfe069afabe5567f919727456f1f12 Review-Url: https://codereview.chromium.org/2684313003 Cr-Commit-Position: refs/heads/master@{#43176}
-
- 13 Feb, 2017 2 commits
-
-
franzih authored
Revert of Remove SIMD.js from V8. (patchset #7 id:120001 of https://codereview.chromium.org/2684313003/ ) Reason for revert: Breaks Node integration build. Original issue's description: > Remove SIMD.js from V8. > > LOG=Y > BUG=v8:4124,v8:5948 > R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org > > Review-Url: https://codereview.chromium.org/2684313003 > Cr-Original-Commit-Position: refs/heads/master@{#43162} > Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c > Review-Url: https://codereview.chromium.org/2684313003 > Cr-Commit-Position: refs/heads/master@{#43169} > Committed: https://chromium.googlesource.com/v8/v8/+/a9b59a11f1bfe069afabe5567f919727456f1f12 TBR=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org,bradnelson@google.com,machenbach@chromium.org,bbudge@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4124,v8:5948 Review-Url: https://codereview.chromium.org/2695653005 Cr-Commit-Position: refs/heads/master@{#43170}
-
bbudge authored
LOG=Y BUG=v8:4124,v8:5948 R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org Review-Url: https://codereview.chromium.org/2684313003 Cr-Original-Commit-Position: refs/heads/master@{#43162} Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c Review-Url: https://codereview.chromium.org/2684313003 Cr-Commit-Position: refs/heads/master@{#43169}
-