Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2611313002:
[complier] Enable parallel eager inner function compilation with compiler dispatcher. (Closed)
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@{#42667}
Committed: https://chromium.googlesource.com/v8/v8/+/6d42c4504a2522e235975a0189c0bd90b6fde47f
Patch Set 1 #
Total comments: 14
Patch Set 2 : Address comments #Patch Set 3 : Move flag #
Total comments: 7
Patch Set 4 : Fix tests #Patch Set 5 : Fix tests #Patch Set 6 : Remove need for ast-value-factory #Patch Set 7 : Rebase #Patch Set 8 : Rebase #Patch Set 9 : Remove --ignition-filter from tests #Patch Set 10 : Fix test #Patch Set 11 : Rebase #Patch Set 12 : Rebase #Patch Set 13 : Rebase and depend on stack size change #Patch Set 14 : Rebase #Patch Set 15 : Add counter for wait time #Patch Set 16 : Rebase #Messages
Total messages: 91 (71 generated)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_android_arm_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_android_arm_compile_rel/...)
rmcilroy@chromium.org changed reviewers: + jochen@chromium.org, marja@chromium.org, mstarzinger@chromium.org
This is still very much a WIP (it needs tests and probably some tweaks to the API), but I thought I would send it out to show the overall plan I have for the compiler dispatcher for eager functions before the Monday meeting. With this change the eager inner functions can be compiled on the background thread in parallel to the outer function, but we still wait for them all to complete before returning from the outer function compilation (I'll look into removing this restriction in future work).
Some initial comments: https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... File src/compiler-dispatcher/compiler-dispatcher.cc (left): https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.cc:343: return; Why? https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.cc:250: return false; Doesn't this break the "if enqueue fails, it must be a stack overflow" logic? This can fail for the above reasons as well? Should this be a CHECK instead? (But esp. the CanEnqueueJobs cannot be made a CHECK I guess, so that'll still break the logic.) https://codereview.chromium.org/2611313002/diff/1/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/2611313002/diff/1/src/compiler.cc#newcode437 src/compiler.cc:437: CompilationInfo* info = job->info(); I'm confused; why is this kind of change needed in this CL? https://codereview.chromium.org/2611313002/diff/1/src/compiler.cc#newcode549 src/compiler.cc:549: if (!isolate->has_pending_exception()) isolate->StackOverflow(); This logic ("if isolate doesn't have a pending exception but something fails, it must be a stack overflow") is now getting scattered even more. Would it be possible to refactor that out somehow (e.g., that the thing that potentially fails would set the stack overflow)? https://codereview.chromium.org/2611313002/diff/1/src/flag-definitions.h File src/flag-definitions.h (right): https://codereview.chromium.org/2611313002/diff/1/src/flag-definitions.h#newc... src/flag-definitions.h:265: DEFINE_BOOL(ignition_staging, false, "use ignition with all staged features") Why are these now moved out of the "Flags for Ignition" section?
https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... File src/compiler-dispatcher/compiler-dispatcher.h (right): https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.h:84: bool Enqueue(Zone* zone, ParseInfo* parse_info, CompilationInfo* compile_info, I wonder whether ParseInfo* and Literal* would be enough. The job could then create the rest it needs from that, no? https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.h:95: void FinishAllNow(); just for the record, I don't think we should have this API long term, but instead of a shared (ref counted) holder for Zone* and just FinishNow() individual jobs
Patchset #2 (id:20001) has been deleted
Description was changed from ========== WIP: [complier] Feed compiler-dispatcher with eager inner function compilation. 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 function. We currently synchronize to ensure all inner funciton compilations are complete before executing the outer function - future work will allow outer function execution to happen in parallel to inner function compilation. BUG=v8:5203,v8:5215 ========== to ========== [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 function. We currently synchronize to ensure all inner function compilations are complete before executing the outer function - future work will allow outer function execution to happen in parallel to inner function compilation. BUG=v8:5203,v8:5215 ==========
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_nosnap_shared_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
Patchset #2 (id:40001) has been deleted
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Changed the API to have the CompilerDispatcherJob now create and own ParseInfo and CompilationInfo. This also meant I had to split the PrepareToCompile step into Analyze and PrepareToCompile. One thing I'm a bit worried about is that the MemoryPressureListener could cause these compilation jobs to be aborted. If we have forced eager compilation (e.g., due to intrinsics or natives syntax) then we wouldn't be able to compile them lazily so this would cause a crash / exception. Jochen - any thoughts on adding a flag to CompileDispatchJob which prevents jobs from being aborted during memory pressure? https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... File src/compiler-dispatcher/compiler-dispatcher.cc (left): https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.cc:343: return; On 2017/01/10 09:58:54, marja wrote: > Why? Opps not sure how that happened - that explains the failing tests... Added back. https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.cc:250: return false; On 2017/01/10 09:58:54, marja wrote: > Doesn't this break the "if enqueue fails, it must be a stack overflow" logic? > This can fail for the above reasons as well? Should this be a CHECK instead? > > (But esp. the CanEnqueueJobs cannot be made a CHECK I guess, so that'll still > break the logic.) Yeah, this was part of the WIP stuff I hadn't quite worked out before our discussion on Monday. I've changed the logic in compiler.cc now so that it tries to enqueue the job, but if that fails, it will compile eagerly there and then. https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... File src/compiler-dispatcher/compiler-dispatcher.h (right): https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.h:84: bool Enqueue(Zone* zone, ParseInfo* parse_info, CompilationInfo* compile_info, On 2017/01/10 09:59:47, jochen wrote: > I wonder whether ParseInfo* and Literal* would be enough. The job could then > create the rest it needs from that, no? I've refactored this to only need the SFI*, Literal* and AstValueFactory*, and have the compiler job create and own the ParseInfo and CompileInfo, which I think is a much clearer API. WDYT? https://codereview.chromium.org/2611313002/diff/1/src/compiler-dispatcher/com... src/compiler-dispatcher/compiler-dispatcher.h:95: void FinishAllNow(); On 2017/01/10 09:59:47, jochen wrote: > just for the record, I don't think we should have this API long term, but > instead of a shared (ref counted) holder for Zone* and just FinishNow() > individual jobs Agreed, that's going to be my next CL. https://codereview.chromium.org/2611313002/diff/1/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/2611313002/diff/1/src/compiler.cc#newcode437 src/compiler.cc:437: CompilationInfo* info = job->info(); On 2017/01/10 09:58:54, marja wrote: > I'm confused; why is this kind of change needed in this CL? The reason is that the MarkToBeExecutedOnce used to be called in CompileUnoptimizedInnerFunctionsRecursively after the function was compiled, however now the function is only enqueued for compile there, so we can't mark the code object. I've moved it here so that it's done when we finalize the compilation job. https://codereview.chromium.org/2611313002/diff/1/src/compiler.cc#newcode549 src/compiler.cc:549: if (!isolate->has_pending_exception()) isolate->StackOverflow(); On 2017/01/10 09:58:54, marja wrote: > This logic ("if isolate doesn't have a pending exception but something fails, it > must be a stack overflow") is now getting scattered even more. Would it be > possible to refactor that out somehow (e.g., that the thing that potentially > fails would set the stack overflow)? I agree this is getting scattered everywhere. I've removed most of these and just kept the one in the outer CompileUnoptimizedCode(). https://codereview.chromium.org/2611313002/diff/1/src/flag-definitions.h File src/flag-definitions.h (right): https://codereview.chromium.org/2611313002/diff/1/src/flag-definitions.h#newc... src/flag-definitions.h:265: DEFINE_BOOL(ignition_staging, false, "use ignition with all staged features") On 2017/01/10 09:58:54, marja wrote: > Why are these now moved out of the "Flags for Ignition" section? When writing this CL I got very confused initially because I had no idea ignition_staging turned on the compiler dispatcher. The compiler_dispatcher (and validate_asm) have nothing to do with Ignition, but we want to turn them on with the ignition-staging config, so I want to pull out the staging config so it's clear all the features this flag turns on, even if they are unrelated to ignition directly.
Description was changed from ========== [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 function. We currently synchronize to ensure all inner function compilations are complete before executing the outer function - future work will allow outer function execution to happen in parallel to inner function compilation. BUG=v8:5203,v8:5215 ========== to ========== [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 ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/20615) v8_win64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng_triggered/b...)
https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:395: result &= FinishNow(it.second.get()); does that work? FinishNow() should delete it from jobs_, at which point we can't advance it anymore? https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:402: jobs_.clear(); jobs_ should already be empty here, no?
https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:395: result &= FinishNow(it.second.get()); On 2017/01/12 13:13:36, jochen wrote: > does that work? FinishNow() should delete it from jobs_, at which point we can't > advance it anymore? This is calling the new FinishNowwith a Job argument, which doesn't delete it from jobs_ https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:402: jobs_.clear(); On 2017/01/12 13:13:36, jochen wrote: > jobs_ should already be empty here, no? As above, the jobs are not deleted by the FinishNow being called here.
compiler-dispatcher/ lgtm
LGTM on compiler plumbing, didn't look at the rest.
I can haz a question: https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:292: AstValueFactory* ast_value_factory) { So now we might access this AstValueFactory from a background thread, right? But the main thread can still add values to it? That doesn't sound safe. Why is that OK? Or is the intention that nobody adds values into AstValueFactory after this point? If that's the case, can you add a debug mechanism for "sealing" the AstValueFactory (so that all funcs which try to add values will DCHECK if we try to call them from here on)? Doesn't compilation also potentially add values (e.g., by accessing the string constants which might not have been accessed before)?
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_nosnap_shared_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...) v8_win_nosnap_shared_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:292: AstValueFactory* ast_value_factory) { On 2017/01/12 16:07:33, marja wrote: > So now we might access this AstValueFactory from a background thread, right? > > But the main thread can still add values to it? > > That doesn't sound safe. Why is that OK? > > Or is the intention that nobody adds values into AstValueFactory after this > point? If that's the case, can you add a debug mechanism for "sealing" the > AstValueFactory (so that all funcs which try to add values will DCHECK if we try > to call them from here on)? > > Doesn't compilation also potentially add values (e.g., by accessing the string > constants which might not have been accessed before)? Yes this is a valid concern. Right now it isn't a problem because we only access the ast_value_factory in the BytecodeGenerator constructor, which happens on the main thread, however we would like to move this off-thread so we should figure out a solution. My thought is that since we only access STRING_CONSTANTS, we could pre-allocate those during isolate initialization, and pre-populate each ast-value-factory with these constants when they are created, that way we wouldn't even need to pass the ast-value-factory here, we could instead get the constants directly from the isolate. I'll have a look into this as a seperate CL.
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_android_arm_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_android_arm_compile_rel/...) v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_gcc_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...) v8_linux_nodcheck_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...) v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/32292) v8_win_compile_dbg on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_compile_dbg/builds/3...)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher.cc (right): https://codereview.chromium.org/2611313002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher.cc:292: AstValueFactory* ast_value_factory) { On 2017/01/13 11:28:02, rmcilroy wrote: > On 2017/01/12 16:07:33, marja wrote: > > So now we might access this AstValueFactory from a background thread, right? > > > > But the main thread can still add values to it? > > > > That doesn't sound safe. Why is that OK? > > > > Or is the intention that nobody adds values into AstValueFactory after this > > point? If that's the case, can you add a debug mechanism for "sealing" the > > AstValueFactory (so that all funcs which try to add values will DCHECK if we > try > > to call them from here on)? > > > > Doesn't compilation also potentially add values (e.g., by accessing the string > > constants which might not have been accessed before)? > > Yes this is a valid concern. Right now it isn't a problem because we only access > the ast_value_factory in the BytecodeGenerator constructor, which happens on the > main thread, however we would like to move this off-thread so we should figure > out a solution. My thought is that since we only access STRING_CONSTANTS, we > could pre-allocate those during isolate initialization, and pre-populate each > ast-value-factory with these constants when they are created, that way we > wouldn't even need to pass the ast-value-factory here, we could instead get the > constants directly from the isolate. I'll have a look into this as a seperate > CL. Removed need for ast-value-factory, does this work for you Marja?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/19231) v8_linux_arm64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel_ng/build...) v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_mac_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng/builds/15668)
Patchset #7 (id:160001) has been deleted
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...) v8_linux64_asan_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng_trig...)
lgtm
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/20955) v8_win_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng_triggered/bui...)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...) v8_linux64_asan_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng_trig...)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by rmcilroy@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org, mstarzinger@chromium.org, marja@chromium.org Link to the patchset: https://codereview.chromium.org/2611313002/#ps240001 (title: "Fix test")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/32562)
The CQ bit was checked by rmcilroy@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org, mstarzinger@chromium.org, marja@chromium.org Link to the patchset: https://codereview.chromium.org/2611313002/#ps260001 (title: "Rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 260001, "attempt_start_ts": 1484663242772110,
"parent_rev": "9e6691fb2f6a3694ae0818dfbd2cec444e94e3af", "commit_rev":
"f12661a1ece4e9c9cb8df5c2d349db960356e604"}
Message was sent while issue was closed.
Description was changed from ========== [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 ========== to ========== [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/+/f12661a1ece4e9c9cb8df5c2d349db96035... ==========
Message was sent while issue was closed.
Committed patchset #11 (id:260001) as https://chromium.googlesource.com/v8/v8/+/f12661a1ece4e9c9cb8df5c2d349db96035...
Message was sent while issue was closed.
A revert of this CL (patchset #11 id:260001) has been created in https://codereview.chromium.org/2637123002/ by machenbach@chromium.org. The reason for reverting is: Some crashes on mac: https://build.chromium.org/p/client.v8/builders/V8%20Mac%20-%20debug/builds/1... https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds....
Message was sent while issue was closed.
On 2017/01/17 15:28:30, Michael Achenbach wrote: > A revert of this CL (patchset #11 id:260001) has been created in > https://codereview.chromium.org/2637123002/ by mailto:machenbach@chromium.org. > > The reason for reverting is: Some crashes on mac: > https://build.chromium.org/p/client.v8/builders/V8%20Mac%20-%20debug/builds/1... > https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds.... Thanks Michael, was just about to do this.
Message was sent while issue was closed.
Description was changed from ========== [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/+/f12661a1ece4e9c9cb8df5c2d349db96035... ========== to ========== [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/+/f12661a1ece4e9c9cb8df5c2d349db96035... ==========
Description was changed from ========== [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/+/f12661a1ece4e9c9cb8df5c2d349db96035... ========== to ========== [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 ==========
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_android_arm_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_android_arm_compile_rel/...) v8_linux64_asan_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...) v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...) v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/19810) v8_linux_arm64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel_ng/build...) v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_dbg_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/19881) v8_linux_gcc_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...) v8_linux_mips64el_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...) v8_linux_mipsel_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mipsel_compile_rel...) v8_linux_nodcheck_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...) v8_linux_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/19779) v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/33217) v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/21524)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_android_arm_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_android_arm_compile_rel/...) v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux_arm64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel_ng/build...) v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_dbg_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/19952) v8_linux_gcc_compile_rel on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...) v8_linux_nodcheck_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...) v8_linux_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/19847) v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/33304) v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/21594)
The CQ bit was checked by rmcilroy@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by rmcilroy@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org, mstarzinger@chromium.org, marja@chromium.org Link to the patchset: https://codereview.chromium.org/2611313002/#ps360001 (title: "Rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 360001, "attempt_start_ts": 1485383993908200,
"parent_rev": "76e31da4f668dbd962456e21634c14d6a12ba37c", "commit_rev":
"6d42c4504a2522e235975a0189c0bd90b6fde47f"}
Message was sent while issue was closed.
Description was changed from ========== [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 ========== to ========== [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@{#42667} Committed: https://chromium.googlesource.com/v8/v8/+/6d42c4504a2522e235975a0189c0bd90b6f... ==========
Message was sent while issue was closed.
Committed patchset #16 (id:360001) as https://chromium.googlesource.com/v8/v8/+/6d42c4504a2522e235975a0189c0bd90b6f... |
