- 30 Apr, 2016 1 commit
-
-
bmeurer authored
Further refactor the pipeline to even run the first scheduler (part of the effect control linearization) concurrently. This temporarily disables most of the write barrier elimination, but we will get back to that later. Drive-by-fix: Remove the dead code from ChangeLowering, and stack allocate the Typer in the pipeline. Also migrate the AllocateStub to a native code builtin, so that we have the code object + a handle to it available all the time. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel R=mstarzinger@chromium.org BUG=v8:4969 LOG=n Review-Url: https://codereview.chromium.org/1926023002 Cr-Commit-Position: refs/heads/master@{#35918}
-
- 26 Apr, 2016 1 commit
-
-
mlippautz authored
Default (and only way) is now to retrieve a tagged object. BUG=chromium:606711 LOG=N Review URL: https://codereview.chromium.org/1922553002 Cr-Commit-Position: refs/heads/master@{#35792}
-
- 19 Apr, 2016 1 commit
-
-
rmcilroy authored
Removes the register file machine register from the interpreter and replaces it will loads from the parent frame pointer. As part of this change the raw operand values for register values changes to enable the interpreter to keep using the operand value as the offset from the parent frame pointer. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1894063002 Cr-Commit-Position: refs/heads/master@{#35618}
-
- 15 Apr, 2016 1 commit
-
-
ahaas authored
The default NaN mode was originally used to identify holes in double arrays. With (https://codereview.chromium.org/863633002/) signalling NaNs are used for that, and the default NaN mode is not needed anymore. Without the default NaN mode it is easier to satisfy the WebAssembly spec which requires that quiet NaNs are preserved. R=titzer@chromium.org, rodolph.perfetta@arm.com, bmeurer@chromium.org Review URL: https://codereview.chromium.org/1884193003 Cr-Commit-Position: refs/heads/master@{#35526}
-
- 06 Apr, 2016 1 commit
-
-
bmeurer authored
Introduce a ResumeGeneratorTrampoline, which does the actual stack state reconstruction (currently always restores a fullcodegen frame), and introduce appropriate TurboFan builtins for %GeneratorPrototype%.next, %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on this native builtin. Also unify the flooding in case of step-in to always work based on JSFunction and remove the special casing for JSGeneratorObject. R=mstarzinger@chromium.org, neis@chromium.org TBR=rossberg@chromium.org BUG=chromium:513471 LOG=n Review URL: https://codereview.chromium.org/1865833002 Cr-Commit-Position: refs/heads/master@{#35283}
-
- 21 Mar, 2016 1 commit
-
-
bmeurer authored
Split ToNumberStub into the entry ToNumberStub, and two new stubs, StringToNumberStub and NonNumberToNumberStub, which can be used when we already know something about the input (i.e. in various branches of the code stubs, or in TurboFan graphs). Also introduce an appropriate StringToNumber simplified operator for TurboFan, that is pure and is lowered to an invocation of the newly added StringToNumberStub. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1818923002 Cr-Commit-Position: refs/heads/master@{#34922}
-
- 15 Mar, 2016 1 commit
-
-
ahaas authored
Implementation of https://codereview.chromium.org/1768233002 on arm. R=titzer@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1778893004 Cr-Commit-Position: refs/heads/master@{#34769}
-
- 14 Mar, 2016 1 commit
-
-
ahaas authored
The previous register allocation allowed invalid register aliasing in cases where in the TF graph the node was used for multiple inputs of the Word32PairShl node. Additionally I renamed PairLsl to LslPair in the code generation for consistency. R=titzer@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1776393004 Cr-Commit-Position: refs/heads/master@{#34755}
-
- 08 Mar, 2016 1 commit
-
-
danno authored
Before this CL, various code stubs used different techniques for marking their frames to enable stack-crawling and other access to data in the frame. All of them were based on a abuse of the "standard" frame representation, e.g. storing the a context pointer immediately below the frame's fp, and a function pointer after that. Although functional, this approach tends to make stubs and builtins do an awkward, unnecessary dance to appear like standard frames, even if they have nothing to do with JavaScript execution. This CL attempts to improve this by: * Ensuring that there are only two fundamentally different types of frames, a "standard" frame and a "typed" frame. Standard frames, as before, contain both a context and function pointer. Typed frames contain only a minimum of a smi marker in the position immediately below the fp where the context is in standard frames. * Only interpreted, full codegen, and optimized Crankshaft and TurboFan JavaScript frames use the "standard" format. All other frames use the type frame format with an explicit marker. * Typed frames can contain one or more values below the type marker. There is new magic macro machinery in frames.h that simplifies defining the offsets of these fields in typed frames. * A new flag in the CallDescriptor enables specifying whether a frame is a standard frame or a typed frame. Secondary register location spilling is now only enabled for standard frames. * A zillion places in the code have been updated to deal with the fact that most code stubs and internal frames use the typed frame format. This includes changes in the deoptimizer, debugger, and liveedit. * StandardFrameConstants::kMarkerOffset is deprecated, (CommonFrameConstants::kContextOrFrameTypeOffset and StandardFrameConstants::kFrameOffset are now used in its stead). LOG=N Review URL: https://codereview.chromium.org/1696043002 Cr-Commit-Position: refs/heads/master@{#34571}
-
- 07 Mar, 2016 2 commits
-
-
ahaas authored
Implementation of https://codereview.chromium.org/1756863002 on arm. R=titzer@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1765973002 Cr-Commit-Position: refs/heads/master@{#34557}
-
ishell authored
HInvokeFunction and HApplyArguments instructions now support tail calling. Inlining of calls at tail position is not supported yet and therefore still disabled. The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft. TBR=bmeurer@chromium.org BUG=v8:4698 LOG=N Review URL: https://codereview.chromium.org/1760253003 Cr-Commit-Position: refs/heads/master@{#34542}
-
- 19 Feb, 2016 1 commit
-
-
bmeurer authored
Move the already existing fast case for %NewObject into a dedicated FastNewObjectStub that we can utilize in places where we would otherwise fallback to %NewObject immediately, which is rather expensive. Also use FastNewObjectStub as the generic implementation of JSCreate, which should make constructor inlining based on SharedFunctionInfo (w/o specializing to a concrete closure) viable soon. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1708313002 Cr-Commit-Position: refs/heads/master@{#34136}
-
- 10 Feb, 2016 1 commit
-
-
mlippautz authored
Preparing the young generation for (real) non-contiguous backing memory, this change removes object masks that are used to compute containment in semi and new space. The masks are replaced by lookups for object tags and page headers, where possible. Details: - Use the fast checks (page header lookups) for containment in regular code. - Use the slow version that masks out the page start adress and iterates all pages of a space for debugging/verification. - The slow version works for off-heap/unmapped memory. - Encapsulate all checks for the old->new barrier in Heap::RecordWrite(). BUG=chromium:581412 LOG=N Review URL: https://codereview.chromium.org/1632913003 Cr-Commit-Position: refs/heads/master@{#33857}
-
- 04 Feb, 2016 1 commit
-
-
mvstanton authored
BUG= Review URL: https://codereview.chromium.org/1647123002 Cr-Commit-Position: refs/heads/master@{#33718}
-
- 28 Jan, 2016 1 commit
-
-
bmeurer authored
The previous versions of Math.max and Math.min made it difficult to optimize those (that's why we already have custom code in Crankshaft), and due to lack of ideas what to do about the variable number of arguments, we will probably need to stick in special code in TurboFan as well; so inlining those builtins is off the table, hence there's no real advantage in having them around as "not quite JS" with extra work necessary in the optimizing compilers to still make those builtins somewhat fast in cases where we cannot inline them (also there's a tricky deopt loop in Crankshaft related to Math.min and Math.max, but that will be dealt with later). So to sum up: Instead of trying to make Math.max and Math.min semi-fast in the optimizing compilers with weird work-arounds support %_Arguments %_ArgumentsLength, we do provide the optimal code as native builtins instead and call it a day (which gives a nice performance boost on some benchmarks). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1641083003 Cr-Commit-Position: refs/heads/master@{#33582}
-
- 22 Jan, 2016 1 commit
-
-
ishell authored
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context. Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context. This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates. BUG=v8:4267 LOG=Y Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f Cr-Commit-Position: refs/heads/master@{#33438} Review URL: https://codereview.chromium.org/1587073003 Cr-Commit-Position: refs/heads/master@{#33461}
-
- 21 Jan, 2016 3 commits
-
-
machenbach authored
Revert of Array length reduction should throw in strict mode if it can't delete an element. (patchset #7 id:220001 of https://codereview.chromium.org/1587073003/ ) Reason for revert: [Sheriff] Breaks layout tests. Please fix upstream. https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077 Original issue's description: > Array length reduction should throw in strict mode if it can't delete an element. > > When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context. > > Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context. > > This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates. > > BUG=v8:4267 > LOG=Y > > Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f > Cr-Commit-Position: refs/heads/master@{#33438} TBR=verwaest@chromium.org,ishell@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4267 Review URL: https://codereview.chromium.org/1611313003 Cr-Commit-Position: refs/heads/master@{#33444}
-
ishell authored
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context. Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context. This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates. BUG=v8:4267 LOG=Y Review URL: https://codereview.chromium.org/1587073003 Cr-Commit-Position: refs/heads/master@{#33438}
-
bmeurer authored
The PrepareId bailout location was used incorrectly in Crankshaft and, as it turns out, is not required anyway (once you do it right). Also there was some premature optimization going on with the CheckEnumCache (trying to load null from roots only once), plus we can be smarter about the null/undefined check anyway. The idea behind this changes is to prepare unification of the two different ForInPrepare implementations that we now have, with the end result being that we only use the new implementation that was recently added for the interpreter. R=jarin@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1618613002 Cr-Commit-Position: refs/heads/master@{#33426}
-
- 20 Jan, 2016 1 commit
-
-
bmeurer authored
We no longer have the concept of "JS builtins" exposed to handwritten native code, so there's no need to keep the InvokeBuiltin macro around. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1611613002 Cr-Commit-Position: refs/heads/master@{#33416}
-
- 15 Jan, 2016 1 commit
-
-
rmcilroy authored
Adds a ForInPrepare Runtime function which returns a triple of cache_type, cache_array and cache_length. This requires adding support to CEntryStub to call runtime functions which return a ObjectTriple - a struct containing three Object* pointers. Also did some cleanup of the x64 CEntryStub to avoid replicated code. Replaces the interpreter's use of the ad-hock InterpreterForInPrepare Runtime function with ForInPrepare in preparation for fixing deopt in BytecodeGraphBuilder for ForIn (which will be done in a followup CL). MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1576093004 Cr-Commit-Position: refs/heads/master@{#33334}
-
- 13 Jan, 2016 1 commit
-
-
bmeurer authored
Also migrate the Number constructor to a native builtin, using the same mechanism already used by the String constructor. Otherwise just parsing and compiling the Number constructor to optimized code already eats 2ms on desktop for no good reason, and the resulting optimized code is not even close to awesome. Drive-by-fix: Use correct context for the [[Construct]] case of the String constructor as well, and share some code with it. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1573243009 Cr-Commit-Position: refs/heads/master@{#33265}
-
- 30 Dec, 2015 1 commit
-
-
cbruni authored
counts specified in runtime.h. In the vast majority of the cases when we call into the runtime we use the default number of arguments. Hence, there is not need to specify it again. This CL also removes TailCallExternalReference as there were no users. BUG= Review URL: https://codereview.chromium.org/1553703002 Cr-Commit-Position: refs/heads/master@{#33066}
-
- 29 Dec, 2015 1 commit
-
-
cbruni authored
JumpToExternalReference ignored the passed-in result_size argument, which defaulted to 1. This change updates all users to not use a result_size. BUG= Review URL: https://codereview.chromium.org/1550923002 Cr-Commit-Position: refs/heads/master@{#33059}
-
- 27 Dec, 2015 2 commits
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 Cr-Commit-Position: refs/heads/master@{#33042} Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33044}
-
bmeurer authored
Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ ) Reason for revert: Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind Original issue's description: > [runtime] Introduce dedicated JSBoundFunction to represent bound functions. > > According to the ES2015 specification, bound functions are exotic > objects, and thus don't need to be implemented as JSFunctions. So > we introduce a new JSBoundFunction type to represent bound functions > and make them optimizable. This already improves the performance of > calling or constructing bound functions by 10-100x depending on the > use case because we avoid the crazy dance between JavaScript and C++ > that was implemented in v8natives.js previously. > > There's still room for improvement in the performance of actually > creating bound functions, which is also relevant in practice, but > we already have a plan how to accomplish that later. > > The mips/mips64 ports were contributed by akos.palfi@imgtec.com. > > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > BUG=chromium:535408, chromium:571299, v8:4629 > LOG=n > > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 > Cr-Commit-Position: refs/heads/master@{#33042} TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:535408, chromium:571299, v8:4629 Review URL: https://codereview.chromium.org/1552473002 Cr-Commit-Position: refs/heads/master@{#33043}
-
- 26 Dec, 2015 1 commit
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33042}
-
- 23 Dec, 2015 1 commit
-
-
hpayer authored
BUG=chromium:561449 LOG=n Review URL: https://codereview.chromium.org/1542113002 Cr-Commit-Position: refs/heads/master@{#33026}
-
- 04 Dec, 2015 3 commits
-
-
yangguo authored
R=verwaest@chromium.org Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290 Cr-Commit-Position: refs/heads/master@{#32553} Committed: https://crrev.com/00559c4584fe3a4c3c1a8d3a5b5af0611b19c40a Cr-Commit-Position: refs/heads/master@{#32600} Review URL: https://codereview.chromium.org/1491743005 Cr-Commit-Position: refs/heads/master@{#32614}
-
machenbach authored
Revert of [debugger] do not predict step in target for liveedit. (patchset #2 id:20001 of https://codereview.chromium.org/1491743005/ ) Reason for revert: [Sheriff] And it still breaks: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3239 Please run chromium trybots on relands of CLs that broke chromium bots. Original issue's description: > [debugger] do not predict step in target for liveedit. > > R=verwaest@chromium.org > > Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290 > Cr-Commit-Position: refs/heads/master@{#32553} > > Committed: https://crrev.com/00559c4584fe3a4c3c1a8d3a5b5af0611b19c40a > Cr-Commit-Position: refs/heads/master@{#32600} TBR=verwaest@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1498523008 Cr-Commit-Position: refs/heads/master@{#32607}
-
yangguo authored
R=verwaest@chromium.org Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290 Cr-Commit-Position: refs/heads/master@{#32553} Review URL: https://codereview.chromium.org/1491743005 Cr-Commit-Position: refs/heads/master@{#32600}
-
- 03 Dec, 2015 2 commits
-
-
machenbach authored
Revert of [debugger] do not predict step in target for liveedit. (patchset #1 id:1 of https://codereview.chromium.org/1491743005/ ) Reason for revert: [Sheriff] Layout test crashes: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3220 Original issue's description: > [debugger] do not predict step in target for liveedit. > > R=verwaest@chromium.org > > Committed: https://crrev.com/8f87ff5d62e996b07ffbde7e735daa603c1d7290 > Cr-Commit-Position: refs/heads/master@{#32553} TBR=verwaest@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1494143002 Cr-Commit-Position: refs/heads/master@{#32565}
-
yangguo authored
R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1491743005 Cr-Commit-Position: refs/heads/master@{#32553}
-
- 27 Nov, 2015 4 commits
-
-
bmeurer authored
Previously all contexts had a link to the global object, but what is required in most cases (except for the global load, store and delete case) is the native context. This also removes the second dummy global object that was still linked to every native context. We will add a different mechanism to ensure that builtins do not pollute the actual global object during bootstrapping. Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel R=yangguo@chromium.org,mstarzinger@chromium.org Committed: https://crrev.com/d290f204938295bfecc5c8e645ccfcff6e80ddb8 Cr-Commit-Position: refs/heads/master@{#32375} Review URL: https://codereview.chromium.org/1480003002 Cr-Commit-Position: refs/heads/master@{#32381}
-
machenbach authored
Revert of [runtime] Replace global object link with native context link in all contexts. (patchset #3 id:40001 of https://codereview.chromium.org/1480003002/ ) Reason for revert: [Sheriff] Breaks: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/5472 Original issue's description: > [runtime] Replace global object link with native context link in all contexts. > > Previously all contexts had a link to the global object, but what is > required in most cases (except for the global load, store and delete > case) is the native context. > > This also removes the second dummy global object that was still linked > to every native context. We will add a different mechanism to ensure > that builtins do not pollute the actual global object during > bootstrapping. > > Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. > > R=yangguo@chromium.org > > Committed: https://crrev.com/d290f204938295bfecc5c8e645ccfcff6e80ddb8 > Cr-Commit-Position: refs/heads/master@{#32375} TBR=yangguo@chromium.org,mstarzinger@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1478303002 Cr-Commit-Position: refs/heads/master@{#32377}
-
bmeurer authored
Previously all contexts had a link to the global object, but what is required in most cases (except for the global load, store and delete case) is the native context. This also removes the second dummy global object that was still linked to every native context. We will add a different mechanism to ensure that builtins do not pollute the actual global object during bootstrapping. Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1480003002 Cr-Commit-Position: refs/heads/master@{#32375}
-
jochen authored
BUG=v8:2487 R=yangguo@chromium.org,jkummerow@chromium.org,mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1474763008 Cr-Commit-Position: refs/heads/master@{#32359}
-
- 26 Nov, 2015 1 commit
-
-
yangguo authored
R=verwaest@chromium.org Committed: https://crrev.com/93eb633214e0f97bf70ae30d2a07b7fbbaa78266 Cr-Commit-Position: refs/heads/master@{#32285} Review URL: https://codereview.chromium.org/1463803002 Cr-Commit-Position: refs/heads/master@{#32339}
-
- 25 Nov, 2015 2 commits
-
-
machenbach authored
Revert of [debugger] flood function for stepping before calling it. (patchset #7 id:120001 of https://codereview.chromium.org/1463803002/ ) Reason for revert: [Sheriff] Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3074 Original issue's description: > [debugger] flood function for stepping before calling it. > > R=verwaest@chromium.org > > Committed: https://crrev.com/93eb633214e0f97bf70ae30d2a07b7fbbaa78266 > Cr-Commit-Position: refs/heads/master@{#32285} TBR=verwaest@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1474943005 Cr-Commit-Position: refs/heads/master@{#32299}
-
yangguo authored
R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1463803002 Cr-Commit-Position: refs/heads/master@{#32285}
-