Bug 120710 - Cached Page and Frame don't need to be ref-counted.
Summary: Cached Page and Frame don't need to be ref-counted.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
URL:
Keywords:
Depends on: 120758
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-04 17:29 PDT by Andreas Kling
Modified: 2013-09-05 14:25 PDT (History)
4 users (show)

See Also:


Attachments
Patch (7.13 KB, patch)
2013-09-04 17:36 PDT, Andreas Kling
andersca: review+
Details | Formatted Diff | Diff
Patch v2 (10.79 KB, patch)
2013-09-05 10:52 PDT, Andreas Kling
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 2013-09-04 17:29:14 PDT
CachedPage and CachedFrame are single-owner objects.
Comment 1 Andreas Kling 2013-09-04 17:36:41 PDT
Created attachment 210530 [details]
Patch
Comment 2 Anders Carlsson 2013-09-04 17:47:14 PDT
Comment on attachment 210530 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=210530&action=review

> Source/WebCore/loader/FrameLoader.cpp:1762
> +            cachedPage = 0;

Nullptr!
Comment 3 Andreas Kling 2013-09-04 18:40:50 PDT
Committed r155086: <http://trac.webkit.org/changeset/155086>
Comment 4 Geoffrey Garen 2013-09-04 22:33:34 PDT
Comment on attachment 210530 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=210530&action=review

> Source/WebCore/loader/FrameLoader.cpp:1747
> +        // Clear out 'cachedPage' right away since it now points to a deleted object.
> +        cachedPage = 0;

This kind of stinks. This function used to be guaranteed-memory-safe by the compiler. Now it's unsafe, with a comment. And the comment doesn't explain how we know our pointer wasn't deleted sooner.

If the memory model is that history().provisionalItem() owns the cached page, perhaps PageCache::get should return PassRefPtr<HistoryItem>, and we just shouldn't put cachedPage into a local variable.
Comment 5 Andreas Kling 2013-09-04 22:38:43 PDT
(In reply to comment #4)
> (From update of attachment 210530 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=210530&action=review
> 
> > Source/WebCore/loader/FrameLoader.cpp:1747
> > +        // Clear out 'cachedPage' right away since it now points to a deleted object.
> > +        cachedPage = 0;
> 
> This kind of stinks. This function used to be guaranteed-memory-safe by the compiler. Now it's unsafe, with a comment. And the comment doesn't explain how we know our pointer wasn't deleted sooner.
> 
> If the memory model is that history().provisionalItem() owns the cached page, perhaps PageCache::get should return PassRefPtr<HistoryItem>, and we just shouldn't put cachedPage into a local variable.

This is not my intended end state, I'm iterating towards having the function rip out an object from the page cache, taking ownership, and eventually grounding it into the new frame.
Comment 6 Geoffrey Garen 2013-09-04 23:30:53 PDT
OK, I will stay tuned for future episodes of the akling show. :)
Comment 7 Andreas Kling 2013-09-05 10:18:12 PDT
Reopening since I reverted this in r155120 for breaking Qt stuffs.
Comment 8 Andreas Kling 2013-09-05 10:52:00 PDT
Created attachment 210637 [details]
Patch v2

Go all the way and add PageCache::take() which lets FrameLoader take ownership of the CachedPage during commitProvisionalLoad().
Comment 9 WebKit Commit Bot 2013-09-05 14:25:46 PDT
Comment on attachment 210637 [details]
Patch v2

Clearing flags on attachment: 210637

Committed r155150: <http://trac.webkit.org/changeset/155150>
Comment 10 WebKit Commit Bot 2013-09-05 14:25:48 PDT
All reviewed patches have been landed.  Closing bug.