- 04 Aug, 2017 1 commit
-
-
Ben L. Titzer authored
Remove the include of frames.h in isolate.h and the include of frames-inl.h from various places, e.g. architecture-specific builtin files. R=yangguo@chromium.org Bug: Change-Id: If8d13188474702fd0b0c298f8e45ef393184b877 Reviewed-on: https://chromium-review.googlesource.com/600212Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47154}
-
- 16 Feb, 2017 1 commit
-
-
Marja Hölttä authored
Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ ) BUG= Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6 Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43238}
-
- 27 Jan, 2017 1 commit
-
-
yangguo authored
Previously, when restarting a frame, we would rewrite all frames between the debugger activation and the frame to restart to squash them, and replace the return address with that of a builtin to leave that rewritten frame, and restart the function by calling it. We now simply remember the frame to drop to, and upon returning from the debugger, we check whether to drop the frame, load the new FP, and restart the function. R=jgruber@chromium.org, mstarzinger@chromium.org BUG=v8:5587 Review-Url: https://codereview.chromium.org/2636913002 Cr-Commit-Position: refs/heads/master@{#42725}
-
- 15 Dec, 2016 1 commit
-
-
jochen authored
Original CL description: > Store SharedFunctionInfos of a Script in a FixedArray indexed by their ID > > Now that SharedFunctionInfos have a unique ID (and the IDs are dense), > we can use them as an index into an array, instead of using a > WeakFixedArray where we have to do a linear scan. > > Hooking up liveedit is a bit more involved, see > https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit > for an overview > > BUG=v8:5589 > R=verwaest@chromium.org,jgruber@chromium.org > > Review-Url: https://codereview.chromium.org/2547483002 BUG=v8:5589 TBR=verwaest@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2577063002 Cr-Commit-Position: refs/heads/master@{#41734}
-
- 14 Dec, 2016 1 commit
-
-
kozyatinskiy authored
Revert of Store SharedFunctionInfos of a Script in a FixedArray indexed by their ID (patchset #11 id:190001 of https://codereview.chromium.org/2547483002/ ) Reason for revert: LiveEdit is broken in some cases. Original issue's description: > Store SharedFunctionInfos of a Script in a FixedArray indexed by their ID > > Now that SharedFunctionInfos have a unique ID (and the IDs are dense), > we can use them as an index into an array, instead of using a > WeakFixedArray where we have to do a linear scan. > > Hooking up liveedit is a bit more involved, see > https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit > for an overview > > BUG=v8:5589 > R=verwaest@chromium.org,jgruber@chromium.org > > Committed: https://crrev.com/6595e7405769dc9d49e9568d61485efc6d468baf > Cr-Commit-Position: refs/heads/master@{#41600} TBR=jgruber@chromium.org,verwaest@chromium.org,yangguo@chromium.org,jochen@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5589,chromium:673950 NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2578433002 Cr-Commit-Position: refs/heads/master@{#41684}
-
- 08 Dec, 2016 1 commit
-
-
jochen authored
Now that SharedFunctionInfos have a unique ID (and the IDs are dense), we can use them as an index into an array, instead of using a WeakFixedArray where we have to do a linear scan. Hooking up liveedit is a bit more involved, see https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit for an overview BUG=v8:5589 R=verwaest@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2547483002 Cr-Commit-Position: refs/heads/master@{#41600}
-
- 06 Sep, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. The (last remaining) offending include path is: ast.h <- liveedit.h <- debug.h <- src/x64/assembler-whatever-port-inl.h <- src/macro-assembler.h <- everything possible With this CL, the rebuild steps needed when touching ast-value-factory.h drops from 365 to 181. BUG=v8:5294 TBR=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2316443002 Cr-Commit-Position: refs/heads/master@{#39195}
-
- 23 Aug, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Fixing it: - Don't include stuff in headers unless necessary. - Include the stuff you need, not some other stuff that happens to include the stuff you need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2268303002 Cr-Commit-Position: refs/heads/master@{#38818}
-
- 09 Aug, 2016 1 commit
-
-
yangguo authored
BUG=v8:5265 Review-Url: https://codereview.chromium.org/2218873002 Cr-Commit-Position: refs/heads/master@{#38482}
-
- 25 Jul, 2016 1 commit
-
-
nikolaos authored
This patch parametrizes AstTraversalVisitor by the actual subclass, in a similar way as AstVisitor is parametrized. This allows a subclass to, e.g., override the Visit method and still use the traversal mechanism. It also allows the subclass to override the specific visiting methods, without them being virtual. This patch also removes AstExpressionVisitor, subsuming its functionality in AstTraversalVisitor. R=adamk@chromium.org, verwaest@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2169833002 Cr-Commit-Position: refs/heads/master@{#37998}
-
- 08 Jun, 2016 1 commit
-
-
mstarzinger authored
This changes the contract for the aforementioned API function to be more permissive and allow callers to call it with less restrictions. The new contract is: a) For so far un-compiled functions, the compiler is free to choose the backend according to other decision criteria. Debug code can hence be provided by either Ignition or FullCodegen. b) For compiled functions, the compiler will provide debug code within the same tier as existing code. For Ignition the generated code will be equivalent to the old one. For FullCodegen the code will contain debug information and debug break slots. Concretely this fixes an issue where generator or async functions might have been compiled with an unexpected backend, due to the fact that the API method in question was always providing FullCodegen code. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2044063002 Cr-Commit-Position: refs/heads/master@{#36808}
-
- 27 May, 2016 1 commit
-
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. BUG= Review-Url: https://codereview.chromium.org/1906823002 Cr-Commit-Position: refs/heads/master@{#36539}
-
- 18 May, 2016 1 commit
-
-
jgruber authored
This moves collection of function information from its previous spot in the standard compiler pipeline (GetSharedFunctionInfo() and CompileTopLevel()) to its new location in CompileForLiveEdit. Nesting information is reconstructed by traversing the AST. R=yangguo@chromium.org BUG= Review-Url: https://codereview.chromium.org/1971683002 Cr-Commit-Position: refs/heads/master@{#36306}
-
- 18 Apr, 2016 1 commit
-
-
mstarzinger authored
This makes sure that the Compiler::CompileForLiveEdit API function uses the common pipeline for top-level code. It ensures that a proper shared function info object is allocated before compilation is triggered. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1900613002 Cr-Commit-Position: refs/heads/master@{#35590}
-
- 08 Mar, 2016 2 commits
-
-
verwaest authored
Also move GetProperty with string-name to JSReceiver BUG= Review URL: https://codereview.chromium.org/1775973002 Cr-Commit-Position: refs/heads/master@{#34596}
-
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}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 1 commit
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
- 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 5 commits
-
-
machenbach authored
Reland of [debugger] do not restart frames that reference new.target for liveedit. (patchset #1 id:1 of https://codereview.chromium.org/1493863004/ ) Reason for revert: Didn't help... Original issue's description: > Revert of [debugger] do not restart frames that reference new.target for liveedit. (patchset #1 id:1 of https://codereview.chromium.org/1493363002/ ) > > Reason for revert: > [Sheriff] Speculative revert for https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3225 > > Original issue's description: > > [debugger] do not restart frames that reference new.target for liveedit. > > > > R=mstarzinger@chromium.org > > > > Committed: https://crrev.com/6fca870240bdbb07a365189b5eb0c98fa65b3682 > > Cr-Commit-Position: refs/heads/master@{#32572} > > TBR=mstarzinger@chromium.org,yangguo@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Committed: https://crrev.com/1a61dab34b9849f3f70a42ce69317e22758c53a1 > Cr-Commit-Position: refs/heads/master@{#32582} TBR=mstarzinger@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1492393003 Cr-Commit-Position: refs/heads/master@{#32587}
-
machenbach authored
Revert of [debugger] do not restart frames that reference new.target for liveedit. (patchset #1 id:1 of https://codereview.chromium.org/1493363002/ ) Reason for revert: [Sheriff] Speculative revert for https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3225 Original issue's description: > [debugger] do not restart frames that reference new.target for liveedit. > > R=mstarzinger@chromium.org > > Committed: https://crrev.com/6fca870240bdbb07a365189b5eb0c98fa65b3682 > Cr-Commit-Position: refs/heads/master@{#32572} TBR=mstarzinger@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1493863004 Cr-Commit-Position: refs/heads/master@{#32582}
-
yangguo authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1493363002 Cr-Commit-Position: refs/heads/master@{#32572}
-
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}
-
- 02 Dec, 2015 1 commit
-
-
mbrandy authored
R=mvstanton@chromium.org, yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/1491683003 Cr-Commit-Position: refs/heads/master@{#32518}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 13 Aug, 2015 1 commit
-
-
yangguo authored
R=mlippautz@chromium.org Review URL: https://codereview.chromium.org/1291043002 Cr-Commit-Position: refs/heads/master@{#30162}
-
- 31 Jul, 2015 1 commit
-
-
yangguo authored
R=cbruni@chromium.org Review URL: https://codereview.chromium.org/1265923002 Cr-Commit-Position: refs/heads/master@{#29951}
-
- 10 Jul, 2015 1 commit
-
-
verwaest authored
For now it uses a pretty slow path for accessing strings by wrapping it into a new temporary wrapper. BUG=v8:4042, v8:3088 LOG=y Review URL: https://codereview.chromium.org/1221303019 Cr-Commit-Position: refs/heads/master@{#29576}
-
- 11 Jun, 2015 1 commit
-
-
verwaest authored
BUG=v8:4137 LOG=n Review URL: https://codereview.chromium.org/1172683003 Cr-Commit-Position: refs/heads/master@{#28946}
-
- 14 Nov, 2014 1 commit
-
-
Andy Wingo authored
R=mvstanton@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/670953003 Cr-Commit-Position: refs/heads/master@{#25348}
-
- 20 Oct, 2014 1 commit
-
-
mvstanton@chromium.org authored
BUG=v8:3605 LOG=N R=jkummerow@chromium.org, ulan@chromium.org Review URL: https://codereview.chromium.org/650073002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24732 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Sep, 2014 1 commit
-
-
mvstanton@chromium.org authored
The TypeFeedbackVector is poised to host significant functionality. While it remains a FixedArray under the covers, we need a place to hold logic and definitions unique to its function. BUG= R=ishell@chromium.org Review URL: https://codereview.chromium.org/581993002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24027 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jun, 2014 1 commit
-
-
yangguo@chromium.org authored
LiveEdit maybe disabled when we enter the break and again when we leave it, but enabled in between. TEST=https://codereview.chromium.org/329533002 R=ulan@chromium.org Review URL: https://codereview.chromium.org/325183003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21770 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-