[Webkit-unassigned] [Bug 90622] blockfreeing thread doesn't need to wake up every 1 second

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Filip Pizlo <fpizlo at apple.com>  2012-07-05 11:14:11 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > void BlockAllocator::blockFreeingThreadMain()
> > > {
> > >     while (!m_blockFreeingThreadShouldQuit) {
> > >         // Generally wait for one second before scavenging free blocks. This
> > >         // may return early, particularly when we're being asked to quit.
> > >         waitForRelativeTime(1.0);
> > >         if (m_blockFreeingThreadShouldQuit)
> > >             break;
> > > 
> > > 
> > > Actually a conditional signal is being used. So the 1 second timeout doesn't seem
> > > necessary.
> > 
> > Where is this imaginary conditional signal?
> > 
> > The block freeing thread does not get signaled when there are free blocks.
> > 
> 
> Hm... I thought m_freeBlockCondition was for that purpose. Sorry for that.

Yeah, it's only to tell the thread to quit, not to wake it up.  The block freeing thread in our GC uses exponential decay.  Once a second it frees half the available blocks.  But there's more: if there was an allocation during the last second then it just waits another second.  So the one second wait is quite necessary for the algorithm to work as intended.  That's not to say that's the best way to free blocks, but it works well, if you consider the requirements: 1) you don't ever want the block freeing thread to free all available blocks all at once because there's always the chance that the main thread will want to allocate blocks in the near future, and there's no way to predict when or if that will happen since it depends on user actions, 2) you want all blocks to be returned to the OS eventually if the browser has gone idle, and 3) you don't want the communication between the main thread and the block freeing thread to involve heavy locks.  The timeout is the best way to
  achieve all of these goals, since it means that even if the browser goes idle for a few seconds, there will still likely be some small number of free blocks left.  In that way, the GC can adapt to whatever level of activity the user imposes.

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