[Webkit-unassigned] [Bug 90622] [BlackBerry] blockfreeing thread doesn't need to wake up frequently when device is idle

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Jul 7 13:39:55 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=90622





--- Comment #6 from Filip Pizlo <fpizlo at apple.com>  2012-07-07 13:39:55 PST ---
(In reply to comment #5)
> I got a local hack for blackberry port. will try to polish it a bit later.

It would be better if we didn't have platform-local hacks in JavaScriptCore.

> 
> Reopening so I won't forget this one for years.

Is the problem that you're seeing once-a-second wake-ups in the block-freeing thread when the device is completely idle?

This is an interesting problem that we could solve correctly: if after N wake-ups (i.e. N seconds) the block freeing thread has not seen any allocations, then it could just free all remaining blocks on its list in one go and then go to sleep with infinite timeout while setting a flag to say that the next time the GC runs, it should broadcast on the condition to re-wake it.  Better yet, instead of having it infinitely wait, the thread could just shut itself down, thereby freeing stack space.

There's the question of what N should be.  We have a number of options:

A) It could just be dependent on the number of free blocks.  The number of free blocks may take a long time to reach zero due to exponential decay, but we could say that if the number of free blocks drops below some threshold (say 2 blocks, or some platform-specific constant that describes the power cost of registering a one-second timeout to do an action instead of doing the action immediately) then we immediately free them and either shut the thread down or infinite sleep, whichever is more appropriate.

B) It could be a constant, like 20, meaning 20 seconds.  This would mean that if the browser goes idle for 20 seconds then we know two things: due to exponential decay, we would have freed 99.9999% of blocks; and probably the browser is likely to continue to be idle so we should just shut down the block freeing thread or sleep infinitely, whichever is more appropriate.

Thoughts?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list