- 08 May, 2017 1 commit
-
-
Loo Rong Jie authored
Bug:v8:5510 R=yangguo@chromium.org,jgruber@chromium.org Change-Id: Ieb355110bd858efe2495a6271ffeda67d41af129 Reviewed-on: https://chromium-review.googlesource.com/497153Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Loo Rong Jie <loorongjie@gmail.com> Cr-Commit-Position: refs/heads/master@{#45151}
-
- 05 May, 2017 1 commit
-
-
bmeurer authored
The collection builtins (Map, Set, WeakMap, WeakSet) are still written in JavaScript and make heavy use of %_ClassOf, which is kind of expensive compared to a simple instance type check. Change that to use simple instance type checks instead. R=jarin@chromium.org BUG=v8:6261,v8:6278,v8:6344 Review-Url: https://codereview.chromium.org/2814773005 Cr-Original-Commit-Position: refs/heads/master@{#45106} Committed: https://chromium.googlesource.com/v8/v8/+/28170099fd1efc84a724ef133f335fec521c0852 Review-Url: https://codereview.chromium.org/2814773005 Cr-Commit-Position: refs/heads/master@{#45124}
-
- 04 May, 2017 2 commits
-
-
bmeurer authored
Revert of [js] Avoid %_ClassOf for collection builtins. (patchset #4 id:60001 of https://codereview.chromium.org/2814773005/ ) Reason for revert: Breaks node.js integration bot: https://build.chromium.org/p/client.v8.fyi/builders/V8%20-%20node.js%20integration/builds/5374/steps/build%20addons%20and%20test%20node.js/logs/stdio Original issue's description: > [js] Avoid %_ClassOf for collection builtins. > > The collection builtins (Map, Set, WeakMap, WeakSet) are still written > in JavaScript and make heavy use of %_ClassOf, which is kind of > expensive compared to a simple instance type check. Change that to use > simple instance type checks instead. > > R=jarin@chromium.org > BUG=v8:6261,v8:6278,v8:6344 > > Review-Url: https://codereview.chromium.org/2814773005 > Cr-Commit-Position: refs/heads/master@{#45106} > Committed: https://chromium.googlesource.com/v8/v8/+/28170099fd1efc84a724ef133f335fec521c0852 TBR=jarin@chromium.org,adamk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6261,v8:6278,v8:6344 Review-Url: https://codereview.chromium.org/2860123002 Cr-Commit-Position: refs/heads/master@{#45108}
-
bmeurer authored
The collection builtins (Map, Set, WeakMap, WeakSet) are still written in JavaScript and make heavy use of %_ClassOf, which is kind of expensive compared to a simple instance type check. Change that to use simple instance type checks instead. R=jarin@chromium.org BUG=v8:6261,v8:6278,v8:6344 Review-Url: https://codereview.chromium.org/2814773005 Cr-Commit-Position: refs/heads/master@{#45106}
-
- 26 Apr, 2017 1 commit
-
-
cwhan.tunz authored
- Throw TypeError in ValidateTypedArray, matching JSC, SpiderMonkey and ChakraCore. - Validate typed arrays at start of each typed array prototype methods in src/js/typedarrays.js - Add tests to check detached buffers - Remove an unnecessary parameter of TypedArraySpeciesCreate in src/js/typedarrays.js - Standardize TypedArray.prototype.subarray - Update test262.status to pass detached buffer tests Reland of https://codereview.chromium.org/2778623003 BUG=v8:4648, v8:4665, v8:4953 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2827443002 Cr-Commit-Position: refs/heads/master@{#44878}
-
- 24 Apr, 2017 1 commit
-
-
Daniel Ehrenberg authored
- Split out code for Intl objects into src/objects/ - Rename i18n to intl (except for the name of the build flag) - Use build system more broadly to turn on/off Intl code - Delete a little bit of dead code Bug: v8:5751 Change-Id: I41bf2825a5cb0df20824922b17c24cae637984da Reviewed-on: https://chromium-review.googlesource.com/481284Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#44801}
-
- 20 Apr, 2017 1 commit
-
-
jkummerow authored
So that we can delete object properties without a runtime call. The builtin implements a few fast paths (for now only deletion of dictionary properties), and calls the runtime for all other cases. Review-Url: https://codereview.chromium.org/2810363003 Cr-Commit-Position: refs/heads/master@{#44740}
-
- 19 Apr, 2017 2 commits
-
-
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}
-
jgruber authored
This changes the message from "method_name is not generic" to "method_name requires that 'this' be a primitive_name object" BUG=v8:6206 Review-Url: https://codereview.chromium.org/2814043006 Cr-Original-Commit-Position: refs/heads/master@{#44683} Committed: https://chromium.googlesource.com/v8/v8/+/21b104e3b83569b52539ecaa83e68a3646065101 Review-Url: https://codereview.chromium.org/2814043006 Cr-Commit-Position: refs/heads/master@{#44713}
-
- 18 Apr, 2017 3 commits
-
-
machenbach authored
Revert of [errors] Improve NotGeneric error message (patchset #3 id:40001 of https://codereview.chromium.org/2814043006/ ) Reason for revert: Please schedule rebasing layout test first: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15036 https://github.com/v8/v8/wiki/Blink-layout-tests Original issue's description: > [errors] Improve NotGeneric error message > > This changes the message from > > "method_name is not generic" > > to > > "method_name requires that 'this' be a primitive_name object" > > BUG=v8:6206 > > Review-Url: https://codereview.chromium.org/2814043006 > Cr-Commit-Position: refs/heads/master@{#44683} > Committed: https://chromium.googlesource.com/v8/v8/+/21b104e3b83569b52539ecaa83e68a3646065101 TBR=littledan@chromium.org,yangguo@chromium.org,jgruber@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6206 Review-Url: https://codereview.chromium.org/2825123002 Cr-Commit-Position: refs/heads/master@{#44701}
-
jgruber authored
This changes the message from "method_name is not generic" to "method_name requires that 'this' be a primitive_name object" BUG=v8:6206 Review-Url: https://codereview.chromium.org/2814043006 Cr-Commit-Position: refs/heads/master@{#44683}
-
mtrofin authored
Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG=chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Original-Commit-Position: refs/heads/master@{#44592} Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44669}
-
- 13 Apr, 2017 1 commit
-
-
Leszek Swirski authored
Currently we count optimizations to decide to disable optimization, and count deopts to detect this decision and allow re-enabling optimizations after a while. However, throwing out TurboFan OSR code and GC optimized code evictions do not count as deopts, which means that the optimization count increases without increasing the deopt count. This increased optimization count disables further optimization -- which is bad, because these are not "true" deopts -- and can stop the optimization from being re-enabled, because the deopt count can't go high enough. Instead, we now only ever look at deopts to disable/re-enable optimization, and opt counts are only used for naming log files and in tests. Change-Id: I0c7d6be497545449a38cf952cd2f007ee51982ba Reviewed-on: https://chromium-review.googlesource.com/468811 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44647}
-
- 12 Apr, 2017 4 commits
-
-
hablich authored
Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ ) Reason for revert: Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824 Original issue's description: > [wasm] instantiate expressed in terms of compile > > Today, the semantics of: > > WebAssembly.instantiate > > and > > WebAssembly.compile().then(new WebAssemblyInstance) > > are subtly different, to the point where attempting the proposed > change uncovered bugs. > > In the future, it's possible that .instantiate actually have different > semantics - if we pre-specialized to the provided ffi, for example. > Right now that's not the case. > > This CL: > - gets our implementation closer to what developers may write using > the compile -> new Instance alternative, in particular wrt promise > creation. By reusing code paths, we uncover more bugs, and keep > maintenance cost lower. > > - it gives us the response-based WebAssembly.instantiate implicitly. > Otherwise, we'd need that same implementation on the blink side. The > negative is maintenance: imagine if the bugs I mentioned could only be > found when running in Blink. > > BUG=chromium:697028 > > Review-Url: https://codereview.chromium.org/2806073002 > Cr-Commit-Position: refs/heads/master@{#44592} > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:697028 Review-Url: https://codereview.chromium.org/2810203002 Cr-Commit-Position: refs/heads/master@{#44614}
-
jgruber authored
This adds a fast path to skip runtime calls to GetSubstitution when the replacer string does not contain a '$' char. Extended background: String.prototype.replace is (roughly) structured as follows: * Check if {searchValue} has a @@replace Symbol, and delegate to that if so. We currently implement efficient fast paths when {searchValue} is a String or a fast RegExp. * A specialized fast path for single-char {searchValue}, "long" subject string, and String {replaceValue} that do not contain '$' chars (yes, this fast path is very specialized). * Check for the location of the first match using StringIndexOf, and exit early if no match is found. * Finally build the return value, which is 'prefix + replacement + suffix', where replacement is either the result of calling {replaceValue} (if it is callable), or GetSubstitution(ToString({replaceValue})) otherwise. There's several spots that could be improved. StringIndexOf currently calls into C++ runtime for all but the simple 1-byte, 1-char {searchValue} case. We need to finally add support for remaining cases. The runtime call to GetSubstitution can be skipped if the replacer string does not contain any '$' syntax. This CL handles that case. BUG= Review-Url: https://codereview.chromium.org/2813843002 Cr-Commit-Position: refs/heads/master@{#44606}
-
Sathya Gunasekaran authored
This change mirrors the semantics for derived class constructors. This change doesn't affect non class constructors. This change could potentially break web compat. More details: https://github.com/tc39/ecma262/pull/469 Bug=v8:5536 Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495 Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#44594}
-
mtrofin authored
Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG=chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44592}
-
- 11 Apr, 2017 3 commits
-
-
littledan authored
The goal of this patch was to refactor NumberFormat parameter handling to be usable by a PluralRules implementation. Along the way, I found and fixed a couple minor issues where options handling differed from the specification, and removed some dead code. Regression tests are added as test262 tests. With this change, the overall flow more closely resembles the specification plus this editorial change which is out for review: https://github.com/tc39/ecma402/pull/130/files BUG=v8:6015,v8:6016 R=yangguo,jungshik Review-Url: https://codereview.chromium.org/2717613005 Cr-Commit-Position: refs/heads/master@{#44571}
-
gsathya authored
This patch implements the runtime semantics of dynamic import. We create a new ASTNode so that we can pass the JSFunction closure() to the runtime function from which we get the script_url. d8 implements the embedder logic required to load and evaluate the modules. The API is mostly implemented as specified. BUG=8:5785 Review-Url: https://codereview.chromium.org/2703563002 Cr-Commit-Position: refs/heads/master@{#44551}
-
aseemgarg authored
BUG=v8:4614 R=binji@chromium.org,jarin@chromium.org Review-Url: https://codereview.chromium.org/2799863002 Cr-Commit-Position: refs/heads/master@{#44542}
-
- 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
-
-
Camillo Bruni authored
Bug: v8/6024 Change-Id: Iff8a1b7a75e9f8f18ac24f31a5275e91aa16a272 Reviewed-on: https://chromium-review.googlesource.com/469347 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#44439}
-
- 04 Apr, 2017 3 commits
-
-
Franziska Hinkelmann authored
Return a structured objet with the type profile information. Move the test from message to mjsunit. BUG=v8:5933 Change-Id: I3e1c592697924d87f82d46b0ddbdb6d82d9c8467 Reviewed-on: https://chromium-review.googlesource.com/464847Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#44364}
-
machenbach authored
Revert of [typedarrays] Check detached buffer at start of typed array methods (patchset #10 id:180001 of https://codereview.chromium.org/2778623003/ ) Reason for revert: Breaks layout tests: https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/18499 Changes: https://storage.googleapis.com/chromium-layout-test-archives/v8_linux_blink_rel/18499/layout-test-results/results.html See: https://github.com/v8/v8/wiki/Blink-layout-tests Original issue's description: > [typedarrays] Check detached buffer at start of typed array methods > > - Throw TypeError in ValidateTypedArray, matching JSC, SpiderMonkey > and ChakraCore. > - Validate typed arrays at start of each typed array prototype > methods in src/js/typedarrays.js > - Add tests to check detached buffers > - Remove an unnecessary parameter of TypedArraySpeciesCreate > in src/js/typedarrays.js > - Standardize TypedArray.prototype.subarray > - Update test262.status to pass detached buffer tests > > BUG=v8:4648,v8:4665,v8:4953 > > Review-Url: https://codereview.chromium.org/2778623003 > Cr-Commit-Position: refs/heads/master@{#44357} > Committed: https://chromium.googlesource.com/v8/v8/+/238d5b4453d9166aaddce76a5393514d977238d4 TBR=cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org,littledan@chromium.org,petermarshall@chromium.org,cwhan.tunz@gmail.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4648,v8:4665,v8:4953 Review-Url: https://codereview.chromium.org/2793233003 Cr-Commit-Position: refs/heads/master@{#44362}
-
cwhan.tunz authored
- Throw TypeError in ValidateTypedArray, matching JSC, SpiderMonkey and ChakraCore. - Validate typed arrays at start of each typed array prototype methods in src/js/typedarrays.js - Add tests to check detached buffers - Remove an unnecessary parameter of TypedArraySpeciesCreate in src/js/typedarrays.js - Standardize TypedArray.prototype.subarray - Update test262.status to pass detached buffer tests BUG=v8:4648,v8:4665,v8:4953 Review-Url: https://codereview.chromium.org/2778623003 Cr-Commit-Position: refs/heads/master@{#44357}
-
- 03 Apr, 2017 1 commit
-
-
Josh Wolfe authored
* When V8_I18N_SUPPORT, completely omit the Unibrow no-op placeholder, and instead use the CPP builtin that uses ICU. * Remove %StringNormalize() runtime function. Bug: v8:5751 CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I3499fa4305d421859253a226f4f09794abe94f4c Change-Id: I3499fa4305d421859253a226f4f09794abe94f4c Reviewed-on: https://chromium-review.googlesource.com/462405Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#44328}
-
- 31 Mar, 2017 2 commits
-
-
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}
-
Clemens Hammacher authored
grow_memory was working from test cases, but not in combination with compiled code. This CL makes the effect of grow_memory executed either in the interpreter or compiled code always be reflected in both execution environments. It also adds a %RedirectToWasmInterpreter runtime function for testing this interaction. R=ahaas@chromium.org CC=gdeepti@chromium.org BUG=v8:5822 Change-Id: I3e7c184c42ef655d1c30d2e0dddad7fb783455fc Reviewed-on: https://chromium-review.googlesource.com/463506 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44297}
-
- 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}
-
- 28 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This removes the static helper which is by now only used by a single runtime function. In general the {Runtime} class no longer acts as a grab-bag for various helper functions. R=petermarshall@chromium.org Change-Id: I9c2141bbd88db27ae1f95fe004bcc8a7c5506208 Reviewed-on: https://chromium-review.googlesource.com/459597 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#44174}
-
- 27 Mar, 2017 4 commits
-
-
Sathya Gunasekaran authored
Previously we threw a generic error meesage on failing hole check for accessing 'this'. But 'this' can be a hole only if the super() has not been called so we change the error message. BUG=v8:5957 Change-Id: I2f0e3d813f16919645d8a5efa7d26e73bd2d83fe Reviewed-on: https://chromium-review.googlesource.com/459085 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#44162}
-
Peter Marshall authored
These aren't used thanks to new implementation in CSA. BUG=v8:5977 Change-Id: Ia4acfa0d1a925eba305a818913cbeff479b27792 Reviewed-on: https://chromium-review.googlesource.com/458477 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44151}
-
Franziska Hinkelmann authored
If used, the TypeProfileSlot is always added as the first slot and its index is constant. If other slots are added before the TypeProfileSlot, this number changes. BUG=v8:5933 Change-Id: I57bc6bea3c48804af28c2d1dafe6a52bdd7d12e3 Reviewed-on: https://chromium-review.googlesource.com/459511Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#44149}
-
Ross McIlroy authored
Since we no longer support the ignition-staging configuration any longer, we can retire the three tier pipeline and the CompileBaseline functionallity. We still need support for JSFunction self healing due to liveedit (which for --no-turbo might end up replacing a forced Ignition function with a FCG function) - we can remove this once we remove --no-turbo support. BUG=v8:4280 Change-Id: I5482abd17785324654e022affd6bdb555b19b181 Reviewed-on: https://chromium-review.googlesource.com/452620 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44141}
-
- 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}
-
- 23 Mar, 2017 1 commit
-
-
ahaas authored
Stack overflow checks are typically implemented as part of the TurboFan graph of a function. This means that the stack check code is executed after frame construction. When a frame is too big, though, there may not be enough space on the stack anymore to throw the stack overflow exception after frame construction. With this CL we do an additional stack check before frame construction for functions with big frames. As discussed offline with mstarzinger, I do this change currently only for WebAssembly. This CL contains only the changes for arm. I will do the other platforms in separate CLs. R=mstarzinger@chromium.org, v8-arm-ports@googlegroups.com Review-Url: https://codereview.chromium.org/2763593002 Cr-Commit-Position: refs/heads/master@{#44065}
-
- 22 Mar, 2017 3 commits
-
-
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}
-
mvstanton authored
Before, we carefully turned on fast array builtins only if flag --enable-fast-array-builtins was true (though it was implied true if --turbo was on). Now, the set of Array.prototype.{some, forEach, every, reduce} is good enough to always turn them on. This means we can remove the JavaScript implementations. The flag is renamed to --experimental-fast-array-builtins, which is off. In the next days we'll add more non-javascript implementations here for testing. BUG= R=danno@chromium.org Review-Url: https://codereview.chromium.org/2761783002 Cr-Commit-Position: refs/heads/master@{#44026}
-
Peter Marshall authored
Deletes unused crankshaft implementation and C++ implementation, which have been replaced by a CSA implementation. BUG=v8:5977 Change-Id: I3614561e45db48583ee886461f98abb14cd9cc4f Reviewed-on: https://chromium-review.googlesource.com/458418 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#44018}
-
- 20 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
This CL adds general lazy compilation support to WebAssembly, according to the design described in the design doc (see referenced bug). It's not used currently, but I tested locally that all tests succeed if I enable it by default. With a later CL, we will enable lazy compilation by default for validate-asm: https://chromium-review.googlesource.com/451318 R=titzer@chromium.org, ahaas@chromium.org, bmeurer@chromium.org BUG=v8:5991 Change-Id: I85440382118a24fc245e78a5a90cf2b95659cd69 Reviewed-on: https://chromium-review.googlesource.com/451317 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43936}
-