|
|
Description[Compiler] Add compile operations to CompilerDispatcherJob.
Adds compile operations to the CompilerDispatcherJob interface. As such,
introduces Compiler::PrepareUnoptimizedCompilationJob and updates the
unoptimized compilation path to use CompilationJobs. Also unifies
FinalizeCompilationJob to deal with both optimized and unoptimized
compilation jobs.
A dummy FullCodegenCompilationJob is also introduced, where all the work
is done in the ExecuteJob phase, which cannot be run on a
background thread.
BUG=v8:5203
Committed: https://crrev.com/c2d2d4d1cea75c838bf9871526772bc155631e9c
Cr-Commit-Position: refs/heads/master@{#38897}
Patch Set 1 #
Total comments: 4
Patch Set 2 : Address comments #
Total comments: 1
Patch Set 3 : Rebase #Patch Set 4 : Address comments #
Total comments: 12
Patch Set 5 : Address Jochen's comments #
Total comments: 4
Patch Set 6 : Address nits #
Total comments: 4
Patch Set 7 : Address Michi's comments. #Patch Set 8 : Fix tests #
Total comments: 2
Patch Set 9 : Fix comment #
Messages
Total messages: 75 (52 generated)
Description was changed from ========== [Compiler] Add compile to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the FinalizeJob phase. BUG=v8:5203 ========== to ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the FinalizeJob phase. BUG=v8:5203 ==========
rmcilroy@chromium.org changed reviewers: + mstarzinger@chromium.org
Michi: what do you think of this general approach? I've tried to centralize the logic for code generation to ensure the synchronous and asynchronous paths all share as much code as possible. As such, I introduced a dummy FullCodegenCompilationJob. If you think this approach is reasonable then I'll add some more tests to CompilerDispatcherJobUnittest and add some more folks on review.
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.
Still struggling to figure out what's wrong with the preceeding CL, but I would appreciate any comments on this CL.
Sorry for the delay, seemed to have fallen through the cracks. Approach looks good to me. Looked at the compiler and the two back-ends, didn't look at the CompilerDispatcherJob all to close. https://codereview.chromium.org/2251713002/diff/1/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/1/src/compiler.h#newcode58 src/compiler.h:58: static CompilationJob* PrepareUnoptimizedCompilationJob( This API method doesn't seem to be used nor implemented. Can we drop it? https://codereview.chromium.org/2251713002/diff/1/src/compiler.h#newcode610 src/compiler.h:610: void RecordCompilationStats() const { nit: I'm not sure the job itself should record stats in the finalization phase. I think it should be the caller who decides whether and how to record stats. Can we remove this helper, make the two rcoed function public and call them directly from within Compiler::FinalizeCompilationJob instead?
https://codereview.chromium.org/2251713002/diff/1/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/1/src/compiler.h#newcode58 src/compiler.h:58: static CompilationJob* PrepareUnoptimizedCompilationJob( On 2016/08/19 10:54:14, Michael Starzinger wrote: > This API method doesn't seem to be used nor implemented. Can we drop it? Ooops, overlooked the obvious. Please disregard this comment.
rmcilroy@chromium.org changed reviewers: + jochen@chromium.org
+Jochen: PTAL at CompilerDispatcherJob changes. https://codereview.chromium.org/2251713002/diff/1/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/1/src/compiler.h#newcode610 src/compiler.h:610: void RecordCompilationStats() const { On 2016/08/19 10:54:14, Michael Starzinger wrote: > nit: I'm not sure the job itself should record stats in the finalization phase. > I think it should be the caller who decides whether and how to record stats. Can > we remove this helper, make the two rcoed function public and call them directly > from within Compiler::FinalizeCompilationJob instead? Done. https://codereview.chromium.org/2251713002/diff/20001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.cc (left): https://codereview.chromium.org/2251713002/diff/20001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:172: HandleScope scope(isolate_); I've removed this HandleScope because the handles created during parser internalization need to be live for compilation.
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 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_mac_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng/builds/7379)
Patchset #3 (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...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: CQ cannot get SignCLA result. Please try later.
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_win64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/12877) 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...)
yeah, I don't think that'll work :-/ e.g. the finalize parsing step creates a bunch of handles, and those won't be valid after the method exists. I started to rewrite that to use DeferredHandleScopes instead. Also, why do we need a second compilationjob, instead of having the compiler-dispatcher-job be "the" job?
On 2016/08/22 15:49:21, jochen wrote: > yeah, I don't think that'll work :-/ You don't think what will work? > e.g. the finalize parsing step creates a bunch of handles, and those won't be > valid after the method exists. I started to rewrite that to use > DeferredHandleScopes instead. Yes, we need to make the finalize step use DeferredHandleScopes, I since nothing is doing anything on background threads yet I didn't update any of those parts yet. > Also, why do we need a second compilationjob, instead of having the > compiler-dispatcher-job be "the" job? We already have CompilationJob for optimized code, and the various compilers have subclasses of the compile job which does the various operations. We could potentially merge them going forward, but I think we would want to have compiler-dispatcher be the mechanism for optimized compile jobs too before we do that.
On 2016/08/22 at 15:54:41, rmcilroy wrote: > On 2016/08/22 15:49:21, jochen wrote: > > yeah, I don't think that'll work :-/ > > You don't think what will work? > > > e.g. the finalize parsing step creates a bunch of handles, and those won't be > > valid after the method exists. I started to rewrite that to use > > DeferredHandleScopes instead. > > Yes, we need to make the finalize step use DeferredHandleScopes, I since nothing is doing anything on background threads yet I didn't update any of those parts yet. background vs foreground doesn't matter here - it's just that the handlescopes go out of context. > > > Also, why do we need a second compilationjob, instead of having the > > compiler-dispatcher-job be "the" job? > > We already have CompilationJob for optimized code, and the various compilers have subclasses of the compile job which does the various operations. We could potentially merge them going forward, but I think we would want to have compiler-dispatcher be the mechanism for optimized compile jobs too before we do that. I'd rather unify the code then. currently, the compilationjob stuff is handled by the optimizing compiler dispatcher.
On 2016/08/22 15:57:06, jochen wrote: > On 2016/08/22 at 15:54:41, rmcilroy wrote: > > On 2016/08/22 15:49:21, jochen wrote: > > > yeah, I don't think that'll work :-/ > > > > You don't think what will work? > > > > > e.g. the finalize parsing step creates a bunch of handles, and those won't > be > > > valid after the method exists. I started to rewrite that to use > > > DeferredHandleScopes instead. > > > > Yes, we need to make the finalize step use DeferredHandleScopes, I since > nothing is doing anything on background threads yet I didn't update any of those > parts yet. > > background vs foreground doesn't matter here - it's just that the handlescopes > go out of context. Right, that's why I removed the extra HandleScope - with that gone we use the parent HandleScope and the handles no longer go out of context when we call the code in-line (which is all the unittests do right now). I'm fine with waiting until you have the DeferredHandleScopes change landed, but didn't think that was necessary given the current WIP state of CompilerDispatcherJob. > > > Also, why do we need a second compilationjob, instead of having the > > > compiler-dispatcher-job be "the" job? > > > > We already have CompilationJob for optimized code, and the various compilers > have subclasses of the compile job which does the various operations. We could > potentially merge them going forward, but I think we would want to have > compiler-dispatcher be the mechanism for optimized compile jobs too before we do > that. > > I'd rather unify the code then. currently, the compilationjob stuff is handled > by the optimizing compiler dispatcher. Let's talk about this tomorrow. I think this would be a really complex change and I would rather we make some forward progress on this without rewriting the whole compilation pipeline. Do you have a plan for integrating all the logic in compiler.cc to figuring out which compiler to use and then dispatching to the appropriate logic in the compilers? We should discuss this with the compiler folks (particularly Michi who knows the subtitles of compiler.cc).
Description was changed from ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the FinalizeJob phase. BUG=v8:5203 ========== to ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the ExecuteJob phase, which cannot be run on a background thread. BUG=v8:5203 ==========
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...
Updated as discussed offline. PTAL, thanks.
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...)
https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.cc (right): https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:143: void CompilerDispatcherJob::PrepareToCompileOnMainThread() { can you make this return a bool that's false if you transition to kFailed? https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:147: compile_info_.reset(new CompilationInfo(parse_info_.get(), function_)); mind putting a DeferredHandleScope here and later using ::Detach() to get the DeferredHandles and pass them to the compilation_info_? https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:168: void CompilerDispatcherJob::Compile() { same here https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:217: compile_info_.reset(); why not also reset the compile_job_? https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.h (right): https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.h:48: } can you also expose this information for the compile step here?
Patchset #5 (id:100001) has been deleted
PTAL https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.cc (right): https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:143: void CompilerDispatcherJob::PrepareToCompileOnMainThread() { On 2016/08/23 12:04:26, jochen wrote: > can you make this return a bool that's false if you transition to kFailed? Done. https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:147: compile_info_.reset(new CompilationInfo(parse_info_.get(), function_)); On 2016/08/23 12:04:26, jochen wrote: > mind putting a DeferredHandleScope here and later using ::Detach() to get the > DeferredHandles and pass them to the compilation_info_? Done. https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:168: void CompilerDispatcherJob::Compile() { On 2016/08/23 12:04:26, jochen wrote: > same here Change this phase to never fail, and always report errors in FinalizeCompilingOnMainThread phase (so that we can throw a StackOverflow exception correctly). https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.cc:217: compile_info_.reset(); On 2016/08/23 12:04:26, jochen wrote: > why not also reset the compile_job_? Opps, done (also for new DeferredHandleScope). https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.h (right): https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.h:48: } On 2016/08/23 12:04:26, jochen wrote: > can you also expose this information for the compile step here? The thing is, this can only return the right value after the CompilationJob is created. Do you want it to blow up if called before kReadyToCompile, or just return false?
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...
lgtm with nits https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.h (right): https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.h:48: } On 2016/08/23 at 15:55:10, rmcilroy wrote: > On 2016/08/23 12:04:26, jochen wrote: > > can you also expose this information for the compile step here? > > The thing is, this can only return the right value after the CompilationJob is created. Do you want it to blow up if called before kReadyToCompile, or just return false? DCHECK and return false, maybe? https://codereview.chromium.org/2251713002/diff/120001/src/compiler-dispatche... File src/compiler-dispatcher/compiler-dispatcher-job.cc (right): https://codereview.chromium.org/2251713002/diff/120001/src/compiler-dispatche... src/compiler-dispatcher/compiler-dispatcher-job.cc:186: handles_from_analysing_.reset(scope.Detach()); why not just compile_info_->set_deferred_handles(scope.Detach())? https://codereview.chromium.org/2251713002/diff/120001/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/120001/src/compiler.h#newcode564 src/compiler.h:564: explicit CompilationJob(Isolate* isolate, CompilationInfo* info, nit. drop explicit
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: 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_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)
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.
https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... File src/compiler-dispatcher/compiler-dispatcher-job.h (right): https://codereview.chromium.org/2251713002/diff/80001/src/compiler-dispatcher... src/compiler-dispatcher/compiler-dispatcher-job.h:48: } On 2016/08/23 16:06:22, jochen wrote: > On 2016/08/23 at 15:55:10, rmcilroy wrote: > > On 2016/08/23 12:04:26, jochen wrote: > > > can you also expose this information for the compile step here? > > > > The thing is, this can only return the right value after the CompilationJob is > created. Do you want it to blow up if called before kReadyToCompile, or just > return false? > > DCHECK and return false, maybe? Done. https://codereview.chromium.org/2251713002/diff/120001/src/compiler-dispatche... File src/compiler-dispatcher/compiler-dispatcher-job.cc (right): https://codereview.chromium.org/2251713002/diff/120001/src/compiler-dispatche... src/compiler-dispatcher/compiler-dispatcher-job.cc:186: handles_from_analysing_.reset(scope.Detach()); On 2016/08/23 16:06:22, jochen wrote: > why not just compile_info_->set_deferred_handles(scope.Detach())? Works for me. Done. https://codereview.chromium.org/2251713002/diff/120001/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/120001/src/compiler.h#newcode564 src/compiler.h:564: explicit CompilationJob(Isolate* isolate, CompilationInfo* info, On 2016/08/23 16:06:22, jochen wrote: > nit. drop explicit Done.
https://codereview.chromium.org/2251713002/diff/140001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/2251713002/diff/140001/src/compiler.cc#newcod... src/compiler.cc:601: InstallUnoptimizedCode(job->info()); This will eventually cause an implicit tier-down once the job is no longer synced with the main thread. Can we at least add a DCHECK(!job->shared()->is_compiled()) before calling InstallUnoptimizedCode so we will see when this hits? https://codereview.chromium.org/2251713002/diff/140001/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/140001/src/compiler.h#newcode584 src/compiler.h:584: void RecordCompilationStats() const { Can we get rid of this helper method and call the two underlying recording function explicitly?
rmcilroy@chromium.org changed reviewers: + jkummerow@chromium.org
+Jakob for Crankshaft changes. https://codereview.chromium.org/2251713002/diff/140001/src/compiler.cc File src/compiler.cc (right): https://codereview.chromium.org/2251713002/diff/140001/src/compiler.cc#newcod... src/compiler.cc:601: InstallUnoptimizedCode(job->info()); On 2016/08/24 07:29:32, Michael Starzinger wrote: > This will eventually cause an implicit tier-down once the job is no longer > synced with the main thread. Can we at least add a > DCHECK(!job->shared()->is_compiled()) before calling InstallUnoptimizedCode so > we will see when this hits? Yes good point. We should make sure the compile dispatcher never finalizes a job for a function which was already compiled on the main thread, but should definitly add this DCHECK to make sure. Done. https://codereview.chromium.org/2251713002/diff/140001/src/compiler.h File src/compiler.h (right): https://codereview.chromium.org/2251713002/diff/140001/src/compiler.h#newcode584 src/compiler.h:584: void RecordCompilationStats() const { On 2016/08/24 07:29:32, Michael Starzinger wrote: > Can we get rid of this helper method and call the two underlying recording > function explicitly? Done.
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...
src/crankshaft/ LGTM.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: 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_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_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...
Patchset #8 (id:180001) 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: This issue passed the CQ dry run.
LGTM. https://codereview.chromium.org/2251713002/diff/190001/src/interpreter/interp... File src/interpreter/interpreter.h (right): https://codereview.chromium.org/2251713002/diff/190001/src/interpreter/interp... src/interpreter/interpreter.h:46: // Creates a compilation job which will generating bytecode for |info|. nit: s/generating/generate/
https://codereview.chromium.org/2251713002/diff/190001/src/interpreter/interp... File src/interpreter/interpreter.h (right): https://codereview.chromium.org/2251713002/diff/190001/src/interpreter/interp... src/interpreter/interpreter.h:46: // Creates a compilation job which will generating bytecode for |info|. On 2016/08/25 08:10:56, Michael Starzinger wrote: > nit: s/generating/generate/ Done.
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, jkummerow@chromium.org, mstarzinger@chromium.org Link to the patchset: https://codereview.chromium.org/2251713002/#ps210001 (title: "Fix comment")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the ExecuteJob phase, which cannot be run on a background thread. BUG=v8:5203 ========== to ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the ExecuteJob phase, which cannot be run on a background thread. BUG=v8:5203 ==========
Message was sent while issue was closed.
Committed patchset #9 (id:210001)
Message was sent while issue was closed.
Description was changed from ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the ExecuteJob phase, which cannot be run on a background thread. BUG=v8:5203 ========== to ========== [Compiler] Add compile operations to CompilerDispatcherJob. Adds compile operations to the CompilerDispatcherJob interface. As such, introduces Compiler::PrepareUnoptimizedCompilationJob and updates the unoptimized compilation path to use CompilationJobs. Also unifies FinalizeCompilationJob to deal with both optimized and unoptimized compilation jobs. A dummy FullCodegenCompilationJob is also introduced, where all the work is done in the ExecuteJob phase, which cannot be run on a background thread. BUG=v8:5203 Committed: https://crrev.com/c2d2d4d1cea75c838bf9871526772bc155631e9c Cr-Commit-Position: refs/heads/master@{#38897} ==========
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/c2d2d4d1cea75c838bf9871526772bc155631e9c Cr-Commit-Position: refs/heads/master@{#38897} |