- 21 Dec, 2016 22 commits
-
-
ishell authored
This is a preliminary step for constant tracking. BUG=v8:5495 Review-Url: https://codereview.chromium.org/2595893002 Cr-Commit-Position: refs/heads/master@{#41899}
-
bjaideep authored
Port 93df0940 Original Commit Message: Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5456 LOG=N Review-Url: https://codereview.chromium.org/2592043003 Cr-Commit-Position: refs/heads/master@{#41898}
-
danno authored
Review-Url: https://codereview.chromium.org/2593033002 Cr-Commit-Position: refs/heads/master@{#41897}
-
leszeks authored
Revert of abstract_code: return compiled code for compiled shared funcs (patchset #2 id:20001 of https://codereview.chromium.org/2592703002/ ) Reason for revert: Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/9970 Original issue's description: > abstract_code: return compiled code for compiled shared funcs > > SharedFunctionInfo's abstract_code was returning the bytecode array > whenever SharedFunctionInfo had a bytecode array, even if the function > was compiled (e.g. tiered up to FCG). This meant that abstract_code > could return code that is not actually the code that will run, which was > causing problems in profiling as the sampled PC did not match the known > code offset. > > This patch changes both SharedFunctionInfo and JSFunction to return the > bytecode if-and-only-if they are not compiled and have a bytecode array > to return, or they already point to the interpreter trampoline. > > BUG=v8:5758 > > Review-Url: https://codereview.chromium.org/2592703002 > Cr-Commit-Position: refs/heads/master@{#41894} > Committed: https://chromium.googlesource.com/v8/v8/+/679b31c21425ecdd86c40a8a02ac131b72f7bc6b TBR=bmeurer@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org,mythria@chromium.org,rmcilroy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5758 Review-Url: https://codereview.chromium.org/2591223002 Cr-Commit-Position: refs/heads/master@{#41896}
-
bbudge authored
On ARM Neon at least, denormals flush to zero, which may not match regular FP behavior. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2598583002 Cr-Commit-Position: refs/heads/master@{#41895}
-
leszeks authored
SharedFunctionInfo's abstract_code was returning the bytecode array whenever SharedFunctionInfo had a bytecode array, even if the function was compiled (e.g. tiered up to FCG). This meant that abstract_code could return code that is not actually the code that will run, which was causing problems in profiling as the sampled PC did not match the known code offset. This patch changes both SharedFunctionInfo and JSFunction to return the bytecode if-and-only-if they are not compiled and have a bytecode array to return, or they already point to the interpreter trampoline. BUG=v8:5758 Review-Url: https://codereview.chromium.org/2592703002 Cr-Commit-Position: refs/heads/master@{#41894}
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2504153002 Cr-Commit-Position: refs/heads/master@{#41893}
-
jgruber authored
The two remaining uses of this intrinsic in debug.js and mirrors.js now simply rely on the runtime function. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2591923003 Cr-Commit-Position: refs/heads/master@{#41892}
-
titzer authored
This is more renaming work to comply with the naming in the public design repository. E.g. types are called "value types" and we no longer refer to ASTs. R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2594993002 Cr-Commit-Position: refs/heads/master@{#41891}
-
jgruber authored
No need to untag/tag flags, and we can also omit the write barrier. BUG=v8:5343 Review-Url: https://codereview.chromium.org/2591193002 Cr-Commit-Position: refs/heads/master@{#41890}
-
titzer authored
Since WASM is no longer an AST :-( R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2594973003 Cr-Commit-Position: refs/heads/master@{#41889}
-
clemensh authored
Also, provide a variadic template Return function for easier use, and refactor the underlying Return function to not use the Buffer, since that might still be needed later (for example if trap code is generated during CallIndirect, and the arguments to the call are stored in the buffer). R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2591903003 Cr-Commit-Position: refs/heads/master@{#41888}
-
littledan authored
The methods Intl.NumberFormat.prototype.v8Parse and Intl.DateTimeFormat.prototype.v8Parse were removed several months ago due to low usage and lack of standardization potential. This patch removes some runtime functions used to implement them, which were accidentally left in when they were taken out. BUG=v8:3785 Review-Url: https://codereview.chromium.org/2591103003 Cr-Commit-Position: refs/heads/master@{#41887}
-
http://crbug.com/675648epertoso authored
R=jarin@chromium.org BUG=675648 Review-Url: https://codereview.chromium.org/2598463003 Cr-Commit-Position: refs/heads/master@{#41886}
-
titzer authored
R=clemensh@chromium.org BUG=chromium:575167 Review-Url: https://codereview.chromium.org/2590243003 Cr-Commit-Position: refs/heads/master@{#41885}
-
alph authored
BUG=chromium:664286 Review-Url: https://codereview.chromium.org/2595673002 Cr-Commit-Position: refs/heads/master@{#41884}
-
jshin authored
Update string-capitalize expected result because now it passes all the tests in the file. Mark fast/js/string-capitalization as failing with no_i18n. Relanding after revert because the failure was taken care of by Adam's CL at https://codereview.chromium.org/2597543002 . BUG=v8:4477, v8:4476 TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*, mjsunit/string-case, intl/general/case* Cr-Original-Commit-Position: refs/heads/master@{#41834} Committed: https://chromium.googlesource.com/v8/v8/+/7c79e23c34ea971947eedc6e42d8a882617c0e47 Review-Url: https://codereview.chromium.org/2588963002 Cr-Commit-Position: refs/heads/master@{#41883}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/53a8a4b..564d650 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/70f42a7..f3dc14e Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fcefe9f..780832e TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2593913002 Cr-Commit-Position: refs/heads/master@{#41882}
-
jyan authored
R=joransiu@ca.ibm.com, bjaideep@ca.ibm.com BUG= Review-Url: https://codereview.chromium.org/2593803003 Cr-Commit-Position: refs/heads/master@{#41881}
-
gsathya authored
BUG=v8:5343 Review-Url: https://codereview.chromium.org/2591033002 Cr-Commit-Position: refs/heads/master@{#41880}
-
gsathya authored
This removes RegExpPrototypeSpeciesGetter and IteratorPrototypeIterator and uses ReturnReceiver builtin instead. This patch also ports the PromiseSpecies to TF by reusing this builtin. BUG=v8:5343 Review-Url: https://codereview.chromium.org/2590373002 Cr-Commit-Position: refs/heads/master@{#41879}
-
adamk authored
The test depends on tricky stack space requirements, so it stopped working in some configurations win FLAG_min_preparse_length was removed in commit 4a5b7e32. As a workaround, pass --no-lazy until the test can be refined to work on all configurations. BUG=v8:5729 TBR=marja@chromium.org Review-Url: https://codereview.chromium.org/2596673002 Cr-Commit-Position: refs/heads/master@{#41878}
-
- 20 Dec, 2016 18 commits
-
-
adamk authored
BUG=v8:4954 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2591853002 Cr-Original-Commit-Position: refs/heads/master@{#41873} Committed: https://chromium.googlesource.com/v8/v8/+/07277202cf136e70c147e2f000e48964332bb01c Review-Url: https://codereview.chromium.org/2591853002 Cr-Commit-Position: refs/heads/master@{#41877}
-
Adam Klein authored
This test requires its objects to live in new space, so running it through gc stress runs just makes it susceptible to flakiness, as was recently seen when turning on the --harmony-string-padding flag (which just adds an extra JS file to the bootstrapper sequence). TBR=ishell@chromium.org, jkummerow@chromium.org Review-Url: https://codereview.chromium.org/2597543002 . Cr-Commit-Position: refs/heads/master@{#41876}
-
gsathya authored
git cl format flagged this while merging Review-Url: https://codereview.chromium.org/2594693003 Cr-Commit-Position: refs/heads/master@{#41875}
-
adamk authored
Revert of Ship String.prototype.pad{Start,End} (patchset #2 id:20001 of https://codereview.chromium.org/2591853002/ ) Reason for revert: Fails on gcstress bot (mjsunit/regress/regress-trap-allocation-memento.js) Original issue's description: > Ship String.prototype.pad{Start,End} > > BUG=v8:4954 > CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel > > Review-Url: https://codereview.chromium.org/2591853002 > Cr-Commit-Position: refs/heads/master@{#41873} > Committed: https://chromium.googlesource.com/v8/v8/+/07277202cf136e70c147e2f000e48964332bb01c TBR=caitp@igalia.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4954 Review-Url: https://codereview.chromium.org/2588423003 Cr-Commit-Position: refs/heads/master@{#41874}
-
adamk authored
BUG=v8:4954 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2591853002 Cr-Commit-Position: refs/heads/master@{#41873}
-
bjaideep authored
Port 53fdf9d1 Original Commit Message: eval() may introduce a scope which needs to be represented as a context at runtime, e.g., eval('var x; let y; ()=>y') introduces a variable y which needs to have a context allocated for it. However, when traversing upwards to find the declaration context for a variable which leaks, as the declaration of x does above, this context has to be understood to not be a declaration context in sloppy mode. This patch makes that distinction by introducing a different map for eval-introduced contexts. A dynamic search for the appropriate context will continue past an eval context to find the appropriate context. Marking contexts as eval contexts rather than function contexts required updates in each compiler backend. R=littledan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5295, chromium:648719 LOG=N Review-Url: https://codereview.chromium.org/2590343002 Cr-Commit-Position: refs/heads/master@{#41872}
-
jshin authored
Move Intl.DateTimeFormat.formatToParts() to HARMONY_SHIPPING bucket. Spec discussion: https://github.com/tc39/ecma402/issues/30 It's in stage 4 and Firefox shipped it in Firefox 51.0. ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts#Browser_compatibility ) BUG=v8:5244 TEST=intl/date-format/date-format-to-parts.js TEST=test262/intl402/DateTimeFormat/prototype/formatToParts/* Review-Url: https://codereview.chromium.org/2585903002 Cr-Commit-Position: refs/heads/master@{#41871}
-
bbudge authored
- Adds Float32x4 Abs, Neg, Equal, NotEqual. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2594683002 Cr-Commit-Position: refs/heads/master@{#41870}
-
littledan authored
eval() may introduce a scope which needs to be represented as a context at runtime, e.g., eval('var x; let y; ()=>y') introduces a variable y which needs to have a context allocated for it. However, when traversing upwards to find the declaration context for a variable which leaks, as the declaration of x does above, this context has to be understood to not be a declaration context in sloppy mode. This patch makes that distinction by introducing a different map for eval-introduced contexts. A dynamic search for the appropriate context will continue past an eval context to find the appropriate context. Marking contexts as eval contexts rather than function contexts required updates in each compiler backend. BUG=v8:5295, chromium:648719 Review-Url: https://codereview.chromium.org/2435023002 Cr-Commit-Position: refs/heads/master@{#41869}
-
bmeurer authored
The %TypedArray% constructor must not ever try to construct an instance, but rather throw a TypeError instead. R=jarin@chromium.org BUG=v8:5763 Review-Url: https://codereview.chromium.org/2587413002 Cr-Commit-Position: refs/heads/master@{#41868}
-
littledan authored
The Intl implementation included manual checks to see if they were being called as a constructor. However, these checks are redundant, as %FunctionRemovePrototype has already marked the functions as un-constructable. This path removes the unnecessary checks. R=yangguo Review-Url: https://codereview.chromium.org/2587713002 Cr-Commit-Position: refs/heads/master@{#41867}
-
titzer authored
R=clemensh@chromium.org CC=rossberg@chromium.org BUG=chromium:575167 Review-Url: https://codereview.chromium.org/2591753002 Cr-Commit-Position: refs/heads/master@{#41866}
-
jochen authored
R=ishell@chromium.org BUG= Review-Url: https://codereview.chromium.org/2590923002 Cr-Commit-Position: refs/heads/master@{#41865}
-
jyan authored
R=joransiu@ca.ibm.com, bjaideep@ca.ibm.com BUG= Review-Url: https://codereview.chromium.org/2589063002 Cr-Commit-Position: refs/heads/master@{#41864}
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2590833002 Cr-Commit-Position: refs/heads/master@{#41863}
-
clemensh authored
The new object will hold information which is shared by all clones of a WasmCompiledModule, e.g. the decoded asm.js offset table, and in the future also breakpoints. From there, we can set them on each new instantiation of any clone. While already changing lots of the code base, I also renamed all getters from "get_foo" to "foo", to conform to the style guide. R=titzer@chromium.org, yangguo@chromium.org BUG=v8:5732 Review-Url: https://codereview.chromium.org/2591653002 Cr-Commit-Position: refs/heads/master@{#41862}
-
marja authored
See tracking bug for more information. BUG=v8:5402 Review-Url: https://codereview.chromium.org/2594663002 Cr-Commit-Position: refs/heads/master@{#41861}
-
jgruber authored
These benchmarks are intended to compare the overhead of async-await vs. a naive promise implementation vs. the babel async-await transformation. The functions in the benchmark don't do any work themselves, so results should reflect only overhead of the chosen implementation. Current numbers on my local machine (higher is better): BaselineES2017-AsyncAwait(Score): 2006 BaselineNaivePromises-AsyncAwait(Score): 7470 Native-AsyncAwait(Score): 3640 BUG=v8:5639 Review-Url: https://codereview.chromium.org/2577393002 Cr-Commit-Position: refs/heads/master@{#41860}
-