1388752 - Add book-keeping to helper thread scheduler to avoid looping over thread list constantly

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Lars T Hansen [:lth]]

See bug 1379814 comment 7 et seq for context.  Basically, the primitive operation in the scheduler is "loop over the list of threads to see if you find any thread meeting these criteria".  Generally those criteria are simple and it's straightforward to just maintain the information in a table of counters instead.  Given that on average we're doing about six loops over the thread list before we find a task to execute, we might have some minor wins here, and in any case it will make the critical section for helper thread execute more quickly, which can't be bad.

Comment 1

[Lars T Hansen [:lth]]

Attachment: bug1388752-thread-accounting-wip.patch

WIP, untested but compiling.

We introduce an idle-thread counter and active-thread counters for each thread type, under the usual lock.  This allows us to get rid of the loop in checkTaskThreadLimit (and further simplify that function by removing an old optimization) and it lets us short-circuit all but one of the remaining task-list scans by testing for the presence of any active task of the desired type.

As accounting happens in the scheduler before the handleWhateverWorkload functions are called, checkTaskThreadLimit must no longer be called from assertions in the handleWhateverWorkload functions.  Small loss - with the scheduler cleanup in bug 1379814 these assertions were clearly redundant.

IMO we should strive to reduce the public surface area of both the GlobalHelperThreadState and HelperThread.  I'm also not currently convinced that all methods that access locked state on the GHTS pass a lock object reference.