- 29 Apr, 2019 1 commit
-
-
Ross McIlroy authored
BUG=v8:8801 Change-Id: Id5ef6219ba2dca2be0603dd0d45e7b27136836e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587391Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61085}
-
- 18 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them. There are at least two changes which this CL produce: - we don't provide break position when we load local variable (still provide when load variable from global), - we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement. More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing Bug: v8:6425 Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda Reviewed-on: https://chromium-review.googlesource.com/543161Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46742}
-
- 14 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
- 27 Mar, 2017 1 commit
-
-
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}
-
- 25 Jan, 2017 1 commit
-
-
rmcilroy authored
Enable enqueueing of eager inner function compilation onto the compiler dispatcher. This enables these tasks to be performed in parallel to compilation of the outer functio (only for Ignition functions). We currently synchronize to ensure all inner function compilations are complete before executing the outer function - future work will allow outer function execution to happenin parallel to inner function compilation. BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2611313002 Cr-Commit-Position: refs/heads/master@{#42667}
-
- 17 Jan, 2017 2 commits
-
-
machenbach authored
Revert of [complier] Enable parallel eager inner function compilation with compiler dispatcher. (patchset #11 id:260001 of https://codereview.chromium.org/2611313002/ ) Reason for revert: Some crashes on mac: https://build.chromium.org/p/client.v8/builders/V8%20Mac%20-%20debug/builds/11982/steps/Ignition%20-%20turbofan/logs/regress-crbug-429159 https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/10966 Original issue's description: > [complier] Enable parallel eager inner function compilation with compiler dispatcher. > > Enable enqueueing of eager inner function compilation onto the compiler > dispatcher. This enables these tasks to be performed in parallel to > compilation of the outer functio (only for Ignition functions). > We currently synchronize to ensure all inner function compilations > are complete before executing the outer function - future work will > allow outer function execution to happenin parallel to inner function > compilation. > > BUG=v8:5203,v8:5215 > > Review-Url: https://codereview.chromium.org/2611313002 > Cr-Commit-Position: refs/heads/master@{#42413} > Committed: https://chromium.googlesource.com/v8/v8/+/f12661a1ece4e9c9cb8df5c2d349db960356e604 TBR=jochen@chromium.org,marja@chromium.org,mstarzinger@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:5203,v8:5215 Review-Url: https://codereview.chromium.org/2637123002 Cr-Commit-Position: refs/heads/master@{#42416}
-
rmcilroy authored
Enable enqueueing of eager inner function compilation onto the compiler dispatcher. This enables these tasks to be performed in parallel to compilation of the outer functio (only for Ignition functions). We currently synchronize to ensure all inner function compilations are complete before executing the outer function - future work will allow outer function execution to happenin parallel to inner function compilation. BUG=v8:5203,v8:5215 Review-Url: https://codereview.chromium.org/2611313002 Cr-Commit-Position: refs/heads/master@{#42413}
-
- 14 Dec, 2016 1 commit
-
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5530 Review-Url: https://codereview.chromium.org/2566093002 Cr-Commit-Position: refs/heads/master@{#41688}
-
- 16 Nov, 2016 1 commit
-
-
jgruber authored
This CL further extends the debug wrapper, migrates around 60 tests, and removes a few tests that use functionality we will not support anymore. In more detail: * Removed tests that use: * enable/disable individual breakpoints * invocationText() * the ScriptCollected event * showBreakPoints * evalFromScript (and similar) * mirror.constructedBy and mirror.referencedBy * event_data.promise() * Some frame.evaluate uses were adapted since due to differences between remote objects (inspector) and mirrors. For instance, exceptions are currently not recreated exactly, since the inspector protocol does not give us the stack and message separately. Other objects (such as 'this' in debug-evaluate-receiver-before-super) need to be explicitly converted to a string before the test works correctly. * Ensure that inspector stores the script before sending ScriptParsed and ScriptFailedToParse events in order to be able to use the script from within those events. * Better remote object reconstruction (e.g. for undefined and arrays). * New functionality in wrapper: * debuggerFlags().breakPointsActive.setValue() * scripts() * execState.setVariableValue() * execState.scopeObject().value() * execState.scopeObject().property() * execState.frame().allScopes() * eventData.exception() * eventData.script() * setBreakPointsActive() BUG=v8:5530 Review-Url: https://codereview.chromium.org/2497973002 Cr-Commit-Position: refs/heads/master@{#41019}
-
- 11 Nov, 2016 1 commit
-
-
jgruber authored
This CL adds support for: * conditional breaks in setBreakpoint, * locals in frame.local{Count,Name,Value}, * evaluation on a frame in frame.evaluate, * and more detailed scope information in scopeObject. Uses of several functions that are not covered by the inspector protocol and are only used in tests have been removed. Local handling has been modified to also include arguments as locals. Inspector differs in this regard from our FrameDetails in that arguments are always shown as locals. Argument-related functions were removed. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2491543002 Cr-Commit-Position: refs/heads/master@{#40917}
-
- 08 Nov, 2016 1 commit
-
-
jgruber authored
This moves all tests currently working with the inspector debugger wrapper to test/debugger. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2480223002 Cr-Commit-Position: refs/heads/master@{#40824}
-
- 07 Nov, 2016 2 commits
-
-
jgruber authored
Revert of [debugger] Migrate more debugger tests to inspector (patchset #2 id:20001 of https://codereview.chromium.org/2480223002/ ) Reason for revert: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/9724 Original issue's description: > [debugger] Migrate more debugger tests to inspector > > This moves all tests currently working with the inspector debugger wrapper to > test/debugger. > > BUG=v8:5530 TBR=yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5530 Review-Url: https://codereview.chromium.org/2480283002 Cr-Commit-Position: refs/heads/master@{#40805}
-
jgruber authored
This moves all tests currently working with the inspector debugger wrapper to test/debugger. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2480223002 Cr-Commit-Position: refs/heads/master@{#40804}
-