The arbitrary-caller "what job is currently running?" state inspector
returns a clone of the JobStatus record for it, not a live reference
to the scheduler's active state. That's appropriate for most cases
but when doing its own internal bookkeeping, the object churn in cloning
(especially, an unneeded clone just for purposes of comparing to some
other job!) is merely a huge waste of CPU and GC load.
So now we don't do that unnecessarily, and everything is much leaner.
Bug
31751985
Change-Id: Idacb52e9e5ca17b9e12b7ccd2fc2e1ec8b3547f6
private boolean isCurrentlyActiveLocked(JobStatus job) {
for (int i=0; i<mActiveServices.size(); i++) {
JobServiceContext serviceContext = mActiveServices.get(i);
- final JobStatus running = serviceContext.getRunningJob();
+ // The 'unsafe' direct-internal-reference running-job inspector is okay to
+ // use here because we are already holding the necessary lock *and* we
+ // immediately discard the returned object reference, if any; we return
+ // only a boolean state indicator to the caller.
+ final JobStatus running = serviceContext.getRunningJobUnsafeLocked();
if (running != null && running.matches(job.getUid(), job.getJobId())) {
return true;
}
return job == null ? null : new JobStatus(job);
}
+ /**
+ * Internal non-cloning inspection of the currently running job, if any. The lock
+ * must be held when calling this *and* for the entire lifetime of using its returned
+ * JobStatus object!
+ */
+ JobStatus getRunningJobUnsafeLocked() {
+ return mRunningJob;
+ }
+
/** Called externally when a job that was scheduled for execution should be cancelled. */
void cancelExecutingJob(int reason) {
mCallbackHandler.obtainMessage(MSG_CANCEL, reason, 0 /* unused */).sendToTarget();