286   // Constructor.
 287   NotifyDoneClosure() {
 288     // Nothing to do.
 289   }
 290   // Virtual destructor because virtual methods.
 291   virtual ~NotifyDoneClosure() {
 292     // Nothing to do.
 293   }
 294 };
 295 
 296 // Dynamic number of GC threads
 297 //
 298 //  GC threads wait in get_task() for work (i.e., a task) to perform.
 299 // When the number of GC threads was static, the number of tasks
 300 // created to do a job was equal to or greater than the maximum
 301 // number of GC threads (ParallelGCThreads).  The job might be divided
 302 // into a number of tasks greater than the number of GC threads for
 303 // load balancing (i.e., over partitioning).  The last task to be
 304 // executed by a GC thread in a job is a work stealing task.  A
 305 // GC  thread that gets a work stealing task continues to execute
 306 // that task until the job is done.  In the static number of GC theads
 307 // case, tasks are added to a queue (FIFO).  The work stealing tasks are
 308 // the last to be added.  Once the tasks are added, the GC threads grab
 309 // a task and go.  A single thread can do all the non-work stealing tasks
 310 // and then execute a work stealing and wait for all the other GC threads
 311 // to execute their work stealing task.
 312 //  In the dynamic number of GC threads implementation, idle-tasks are
 313 // created to occupy the non-participating or "inactive" threads.  An
 314 // idle-task makes the GC thread wait on a barrier that is part of the
 315 // GCTaskManager.  The GC threads that have been "idled" in a IdleGCTask
 316 // are released once all the active GC threads have finished their work
 317 // stealing tasks.  The GCTaskManager does not wait for all the "idled"
 318 // GC threads to resume execution. When those GC threads do resume
 319 // execution in the course of the thread scheduling, they call get_tasks()
 320 // as all the other GC threads do.  Because all the "idled" threads are
 321 // not required to execute in order to finish a job, it is possible for
 322 // a GC thread to still be "idled" when the next job is started.  Such
 323 // a thread stays "idled" for the next job.  This can result in a new
 324 // job not having all the expected active workers.  For example if on
 325 // job requests 4 active workers out of a total of 10 workers so the
 326 // remaining 6 are "idled", if the next job requests 6 active workers

 286   // Constructor.
 287   NotifyDoneClosure() {
 288     // Nothing to do.
 289   }
 290   // Virtual destructor because virtual methods.
 291   virtual ~NotifyDoneClosure() {
 292     // Nothing to do.
 293   }
 294 };
 295 
 296 // Dynamic number of GC threads
 297 //
 298 //  GC threads wait in get_task() for work (i.e., a task) to perform.
 299 // When the number of GC threads was static, the number of tasks
 300 // created to do a job was equal to or greater than the maximum
 301 // number of GC threads (ParallelGCThreads).  The job might be divided
 302 // into a number of tasks greater than the number of GC threads for
 303 // load balancing (i.e., over partitioning).  The last task to be
 304 // executed by a GC thread in a job is a work stealing task.  A
 305 // GC  thread that gets a work stealing task continues to execute
 306 // that task until the job is done.  In the static number of GC threads
 307 // case, tasks are added to a queue (FIFO).  The work stealing tasks are
 308 // the last to be added.  Once the tasks are added, the GC threads grab
 309 // a task and go.  A single thread can do all the non-work stealing tasks
 310 // and then execute a work stealing and wait for all the other GC threads
 311 // to execute their work stealing task.
 312 //  In the dynamic number of GC threads implementation, idle-tasks are
 313 // created to occupy the non-participating or "inactive" threads.  An
 314 // idle-task makes the GC thread wait on a barrier that is part of the
 315 // GCTaskManager.  The GC threads that have been "idled" in a IdleGCTask
 316 // are released once all the active GC threads have finished their work
 317 // stealing tasks.  The GCTaskManager does not wait for all the "idled"
 318 // GC threads to resume execution. When those GC threads do resume
 319 // execution in the course of the thread scheduling, they call get_tasks()
 320 // as all the other GC threads do.  Because all the "idled" threads are
 321 // not required to execute in order to finish a job, it is possible for
 322 // a GC thread to still be "idled" when the next job is started.  Such
 323 // a thread stays "idled" for the next job.  This can result in a new
 324 // job not having all the expected active workers.  For example if on
 325 // job requests 4 active workers out of a total of 10 workers so the
 326 // remaining 6 are "idled", if the next job requests 6 active workers