- 16 Apr, 2015 2 commits
-
-
Benedikt Meurer authored
TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1091723002 Cr-Commit-Position: refs/heads/master@{#27861}
-
v8-autoroll authored
Rolling v8/tools/clang to 32e839da8bd2088ef23c3ea874d3c1cd04cd1384 TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/1093493002 Cr-Commit-Position: refs/heads/master@{#27860}
-
- 15 Apr, 2015 34 commits
-
-
adamk authored
This reverts commit 8c98cc07 because it causes flaky failures in the dromaeo.jslibeventprototype benchmark on Linux/Windows and consistent failures on Android. Also reverts the followup "Remove kForInStatementIsNotFastCase bailout reason" (commit ba24e676) to avoid breaking the build. BUG=chromium:476592 TBR=verwaest@chromium.org LOG=y Review URL: https://codereview.chromium.org/1066663005 Cr-Commit-Position: refs/heads/master@{#27859}
-
wingo authored
R=arv@chromium.org BUG= Review URL: https://codereview.chromium.org/1083953002 Cr-Commit-Position: refs/heads/master@{#27858}
-
mvstanton authored
Calling new Array(JSObject::kInitialMaxFastElementArray) in optimized code makes a stub call that bails out due to the length. Currently, the bailout code a) doesn't have the allocation site, and b) wouldn't use it if it did because the length is perceived to be too high. This CL passes the allocation site to the stub call (rather than undefined), and alters the bailout code to utilize the feedback. BUG= Review URL: https://codereview.chromium.org/1086873003 Cr-Commit-Position: refs/heads/master@{#27857}
-
machenbach authored
Revert of Simplify DoParseProgram (patchset #2 id:20001 of https://codereview.chromium.org/1058363003/) Reason for revert: [Sheriff] Changes some layout tests on all platforms, e.g.: http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2032/builds/2543 Original issue's description: > Simplify DoParseProgram > > DoParseProgram doesn't appear to need to receive toplevel scopes as > arguments; it can properly set the end_position of the scopes to the > scanner's position after parsing is complete. > > R=marja@chromium.org > BUG= > LOG=N > > Committed: https://crrev.com/8da9252f61d3c499a78b0b94299c314b2eb0b0c8 > Cr-Commit-Position: refs/heads/master@{#27847} TBR=marja@chromium.org,wingo@igalia.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1089623002 Cr-Commit-Position: refs/heads/master@{#27856}
-
arv authored
In ES6 function name and length are configurable. However, the length and name properties of the poison pill function must not be configurable. BUG=v8:4011 LOG=N R=adamk@chromium.org, rossberg@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1061393002 Cr-Commit-Position: refs/heads/master@{#27855}
-
scottmg authored
enum defaults to signed on win, and kTagged has 1<<31 causing warning. Full errors: d:\src\cr3\src\v8\src\types.cc(1259): error C2220: warning treated as error - no 'object' file generated d:\src\cr3\src\v8\src\types.cc(1241): note: while compiling class template member function 'void v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::BitsetType::Print(std::ostream &,v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::bitset)' d:\src\cr3\src\v8\src\types.cc(1283): note: see reference to function template instantiation 'void v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::BitsetType::Print(std::ostream &,v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::bitset)' being compiled d:\src\cr3\src\v8\src\types.cc(1355): note: see reference to class template instantiation 'v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::BitsetType' being compiled d:\src\cr3\src\v8\src\types.cc(1259): warning C4838: conversion from 'int' to 'const v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::bitset' requires a narrowing conversion d:\src\cr3\src\v8\src\types.cc(1259): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings d:\src\cr3\src\v8\src\types.cc(323): warning C4838: conversion from '' to 'v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::bitset' requires a narrowing conversion d:\src\cr3\src\v8\src\types.cc(323): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings d:\src\cr3\src\v8\src\types.cc(315): note: while compiling class template static data member 'const v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::BitsetType::Boundary v8::internal::TypeImpl<v8::internal::ZoneTypeConfig>::BitsetType::BoundariesArray[]' d:\src\cr3\src\v8\src\types.cc(1259): warning C4838: conversion from 'int' to 'const v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::bitset' requires a narrowing conversion d:\src\cr3\src\v8\src\types.cc(1259): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings d:\src\cr3\src\v8\src\types.cc(1241): note: while compiling class template member function 'void v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::BitsetType::Print(std::ostream &,v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::bitset)' d:\src\cr3\src\v8\src\types.cc(1283): note: see reference to function template instantiation 'void v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::BitsetType::Print(std::ostream &,v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::bitset)' being compiled d:\src\cr3\src\v8\src\types.cc(1359): note: see reference to class template instantiation 'v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::BitsetType' being compiled d:\src\cr3\src\v8\src\types.cc(323): warning C4838: conversion from '' to 'v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::bitset' requires a narrowing conversion d:\src\cr3\src\v8\src\types.cc(323): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings d:\src\cr3\src\v8\src\types.cc(315): note: while compiling class template static data member 'const v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::BitsetType::Boundary v8::internal::TypeImpl<v8::internal::HeapTypeConfig>::BitsetType::BoundariesArray[]' LOG=N R=jochen@chromium.org BUG=440500 Review URL: https://codereview.chromium.org/1055933004 Cr-Commit-Position: refs/heads/master@{#27854}
-
scottmg authored
LOG=N R=jochen@chromium.org BUG=chromium:440500 Review URL: https://codereview.chromium.org/1084763002 Cr-Commit-Position: refs/heads/master@{#27853}
-
Jakob Kummerow authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1085283002 Cr-Commit-Position: refs/heads/master@{#27852}
-
erikcorry authored
R=jkummerow@chromium.org BUG=chromium:475705 LOG=y Review URL: https://codereview.chromium.org/1082763002 Cr-Commit-Position: refs/heads/master@{#27851}
-
mbrandy authored
Port c8e4d57d Original commit message: They are content with a dummy vector, as MISSES won't result in changing the real vector/slot at all. R=mvstanton@chromium.org, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1085913003 Cr-Commit-Position: refs/heads/master@{#27850}
-
mbrandy authored
Port 0179ec57 Original commit message: The cells are stored on prototypes (in their map's PrototypeInfo). When a prototype object changes its map, then both its own validity cell and those of all "downstream" prototypes are invalidated; handlers for a given receiver embed the currently valid cell for that receiver's prototype during their compilation and check it on execution. R=michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1091563002 Cr-Commit-Position: refs/heads/master@{#27849}
-
jkummerow authored
AFAICT none of these can actually be triggered currently; but it's still good to harden the code a little. Review URL: https://codereview.chromium.org/1058533007 Cr-Commit-Position: refs/heads/master@{#27848}
-
wingo authored
DoParseProgram doesn't appear to need to receive toplevel scopes as arguments; it can properly set the end_position of the scopes to the scanner's position after parsing is complete. R=marja@chromium.org BUG= LOG=N Review URL: https://codereview.chromium.org/1058363003 Cr-Commit-Position: refs/heads/master@{#27847}
-
mstarzinger authored
This adds a missing bailout id to a ForInStatement for when retrieving and filtering a property name deoptimizes. This can happen with proxies that have a getPropertyDescriptor trap. R=jarin@chromium.org TEST=mjsunit/for-in-opt Review URL: https://codereview.chromium.org/1086083002 Cr-Commit-Position: refs/heads/master@{#27846}
-
jkummerow authored
The cells are stored on prototypes (in their map's PrototypeInfo). When a prototype object changes its map, then both its own validity cell and those of all "downstream" prototypes are invalidated; handlers for a given receiver embed the currently valid cell for that receiver's prototype during their compilation and check it on execution. Review URL: https://codereview.chromium.org/908213002 Cr-Commit-Position: refs/heads/master@{#27845}
-
mvstanton authored
Ensure that we protect turning off the vector ics flag. BUG= R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1087213002 Cr-Commit-Position: refs/heads/master@{#27844}
-
mstarzinger authored
R=verwaest@chromium.org TEST=cctest/test-api BUG=v8:3995 LOG=N Review URL: https://codereview.chromium.org/1058553004 Cr-Commit-Position: refs/heads/master@{#27843}
-
dcarney authored
- make ParallelMove into a ZoneVector, removing an annoying level of indirection - make MoveOperands hold InstructionOperands instead of pointers, so there's no more operand aliasing for moves - opens up possibility of storing MachineType in allocated operands R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1081373002 Cr-Commit-Position: refs/heads/master@{#27842}
-
hablich authored
Polls omahaproxy for data about Chrome releases BUG= NOTRY=true Review URL: https://codereview.chromium.org/1063073003 Cr-Commit-Position: refs/heads/master@{#27841}
-
ulan authored
This fixes TSAN failure caused by race between: - optimizing compiler thread setting climit - and json parser reading climit in the main thread. BUG= Review URL: https://codereview.chromium.org/1031223004 Cr-Commit-Position: refs/heads/master@{#27840}
-
yangguo authored
R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1090563002 Cr-Commit-Position: refs/heads/master@{#27839}
-
yangguo authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/1089533002 Cr-Commit-Position: refs/heads/master@{#27838}
-
ulan authored
BUG=v8:4027 LOG=NO Review URL: https://codereview.chromium.org/1086063003 Cr-Commit-Position: refs/heads/master@{#27837}
-
danno authored
Review URL: https://codereview.chromium.org/985023002 Cr-Commit-Position: refs/heads/master@{#27836}
-
jkummerow authored
This is a partial revert of 3eb277f2. R=machenbach@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1087183002 Cr-Commit-Position: refs/heads/master@{#27835}
-
machenbach authored
Revert of Force full GCwhenever CollectAllGarbage is meant to trigger a full GC. (patchset #4 id:60001 of https://codereview.chromium.org/1082973003/) Reason for revert: [Sheriff] Breaks http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/3348 and maybe leads to timeouts/crashes on layout test bots: http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064/builds/3002 Original issue's description: > Force full GC whenever CollectAllGarbage is meant to trigger a full GC. > > Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site. > > Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC. > > BUG= > > Committed: https://crrev.com/9c105f0940ba757364ac18fcdf649815ec5ab2d1 > Cr-Commit-Position: refs/heads/master@{#27831} TBR=ulan@chromium.org,hpayer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1088083002 Cr-Commit-Position: refs/heads/master@{#27834}
-
jochen authored
The embedder can control how many threads it wants to use via the v8::Platform implementation. V8 internally doesn't spin up threads anymore. If the embedder doesn't want to use any threads at all, it's v8::Platform implementation must either run the background jobs on the foreground thread, or the embedder should specify --predictable BUG=none R=yangguo@chromium.org LOG=y Review URL: https://codereview.chromium.org/1064723005 Cr-Commit-Position: refs/heads/master@{#27833}
-
jochen authored
An embedder that wants to avoid the check should use MaybeLocal::ToLocal. BUG=none R=dcarney@chromium.org LOG=y Review URL: https://codereview.chromium.org/1083943002 Cr-Commit-Position: refs/heads/master@{#27832}
-
hpayer authored
Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site. Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC. BUG= Review URL: https://codereview.chromium.org/1082973003 Cr-Commit-Position: refs/heads/master@{#27831}
-
svenpanne authored
Review URL: https://codereview.chromium.org/1065443004 Cr-Commit-Position: refs/heads/master@{#27830}
-
bmeurer authored
Before we always loaded smi zero via a movabs with a 64-bit immediate, which is pretty expensive compared to the xorl. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1085153002 Cr-Commit-Position: refs/heads/master@{#27829}
-
v8-autoroll authored
Rolling v8/build/gyp to 2a5511bd901f328db10d0b6415c864a5ff59fc81 Rolling v8/tools/clang to 330d3b5bd0ecf77d0d612081ba058ba01adfb67b TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/1091453002 Cr-Commit-Position: refs/heads/master@{#27828}
-
mvstanton authored
This needs "Pass load ic state through the Oracle" (https://codereview.chromium.org/1083933002/) to land first. BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/1083083002 Cr-Commit-Position: refs/heads/master@{#27827}
-
mvstanton authored
We'd like to know in optimized code with more precision what feedback state was achieved for a load. R=dcarney@chromium.org BUG= Review URL: https://codereview.chromium.org/1083933002 Cr-Commit-Position: refs/heads/master@{#27826}
-
- 14 Apr, 2015 4 commits
-
-
paul.lind authored
Port 5d2de78a BUG= Review URL: https://codereview.chromium.org/1085693003 Cr-Commit-Position: refs/heads/master@{#27825}
-
wingo authored
R=arv@chromium.org, adamk@chromium.org, marja@chromium.org BUG=v8:4020 LOG=N Review URL: https://codereview.chromium.org/1061983004 Cr-Commit-Position: refs/heads/master@{#27824}
-
mbrandy authored
Port 5d2de78a Original commit message: It's cheaper to materialize heap constants by loading from the roots array instead of embedding the constant into the instruction stream, at least on x64, arm and arm64. Drive-by-fix: Also cleanup the materialize constant from frame optimization. R=michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1075303003 Cr-Commit-Position: refs/heads/master@{#27823}
-
jkummerow authored
Review URL: https://codereview.chromium.org/1086923002 Cr-Commit-Position: refs/heads/master@{#27822}
-