53
edits
DocShell/Fastback: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 13: | Line 13: | ||
It's possible that the size of the docshell has changed since the presentation was stored. In this case, we need to resize the root view's widget to match the new size. This will cause the necessary reflows and repainting to occur. | It's possible that the size of the docshell has changed since the presentation was stored. In this case, we need to resize the root view's widget to match the new size. This will cause the necessary reflows and repainting to occur. | ||
== Eviction from history == | |||
The number of content viewers in session history is limited based on the physical memory on the system. Currently, there is a fixed limit which is a logarithmic function of the memory size, with a maximum of 8 cached viewers. | |||
On top of this global limit, we limit each nsSHistory instance (which corresponds to each browser tab) to a maximum of 3 cached content viewers. This avoids wasting memory for viewers which the user is very unlikely to revisit. | |||
Once a new content viewer has been placed into session history through a call to DocumentViewerImpl::Destroy, nsSHistory::EvictContentViewers is called. It first checks the limit for the current nsSHistory object, by determining a sliding window of SHEntrry indices which are allowed to have cached viewers. The sliding window has an endpoint at the new current index, and the other endpoint is 3 back (if we're going forward) or 3 in front (if we're going backward). Any viewers outside of this range are evicted. Next, it checks against the global limit, by computing the sliding window for each nsSHistory. The viewer which is the furthest away from its SHistory's current index is considered the best eviction candidate, because it's the least recently used across the app. At the end of this process, we have a count of all cached content viewers. If it's more than the fixed limit, we evict the one that was furthest away. If we still need to evict viewers to reach the limit, we start the entire process again. | |||
This algorithm is inefficient (O(n^2)) in the worst case, but O(n) in the common case, since we'll rarely need to evict more than one viewer -- only if the user manually changes the pref that controls the limit. There is a fast path for "clear history" which evicts all cached viewers in O(n) time. | |||