Bug 135727 - Cached file backed resources don't make it to the Web Process when NETWORK_CFDATA_ARRAY_CALLBACK is enabled
Summary: Cached file backed resources don't make it to the Web Process when NETWORK_CF...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Pratik Solanki
URL:
Keywords: InRadar
Depends on:
Blocks: 135554
  Show dependency treegraph
 
Reported: 2014-08-07 15:08 PDT by Pratik Solanki
Modified: 2014-08-12 15:51 PDT (History)
4 users (show)

See Also:


Attachments
Patch (5.35 KB, patch)
2014-08-07 18:17 PDT, Pratik Solanki
no flags Details | Formatted Diff | Diff
Patch2 (4.79 KB, patch)
2014-08-11 11:56 PDT, Pratik Solanki
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pratik Solanki 2014-08-07 15:08:56 PDT
If we have a resource that is file backed in CFNetwork, then we try to send that data over to the web process so that the web process uses file backed memory. Unfortunately, this is not working on iOS because iOS uses the data array calbacks. We have this check in NetworkResourceLoader::tryGetShareableHandleFromSharedBuffer().

    if (!buffer->hasPlatformData())
        return;

For data array callbacks, hasPlatformData() will return false since SharedBuffer has a data array and not a single CFDataRef. This breaks the optimization. If I comment out the above code and fall through, the code does

    RetainPtr<CFDataRef> data = buffer->createCFData();
    if (_CFURLCacheIsResponseDataMemMapped(cache, data.get()) == kCFBooleanFalse)
        return;


createCFData() will do the right thing and the CFNetwork SPI will return true which will make our optimization work again.

The second mechanism - the disk cache notification works fine.
Comment 1 Pratik Solanki 2014-08-07 15:09:32 PDT
<rdar://problem/17947880>
Comment 2 Pratik Solanki 2014-08-07 18:17:20 PDT
Created attachment 236251 [details]
Patch
Comment 3 Pratik Solanki 2014-08-07 18:18:48 PDT
Comment on attachment 236251 [details]
Patch

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

> Source/WebCore/ChangeLog:16
> +        (WebCore::SharedBuffer::createCFData):

Is there a better name I could use for getCFDataIfAvailable? I don't like the mismatch of get and create but createCFDataIfAvailable() seemed odd.
Comment 4 Alexey Proskuryakov 2014-08-07 20:58:36 PDT
Comment on attachment 236251 [details]
Patch

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

>> Source/WebCore/ChangeLog:16
>> +        (WebCore::SharedBuffer::createCFData):
> 
> Is there a better name I could use for getCFDataIfAvailable? I don't like the mismatch of get and create but createCFDataIfAvailable() seemed odd.

createCFDataIfInternallyRepresentedAsCFData()? createCFDataNoCopy()?
Comment 5 Pratik Solanki 2014-08-07 22:39:16 PDT
Comment on attachment 236251 [details]
Patch

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

>>> Source/WebCore/ChangeLog:16
>>> +        (WebCore::SharedBuffer::createCFData):
>> 
>> Is there a better name I could use for getCFDataIfAvailable? I don't like the mismatch of get and create but createCFDataIfAvailable() seemed odd.
> 
> createCFDataIfInternallyRepresentedAsCFData()? createCFDataNoCopy()?

copyCFDataNoCreate() ?
Comment 6 Pratik Solanki 2014-08-11 11:56:06 PDT
Created attachment 236390 [details]
Patch2

I like copyCFDataNoCreate. Patch with new name.
Comment 7 Darin Adler 2014-08-11 22:30:01 PDT
Comment on attachment 236390 [details]
Patch2

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

> Source/WebCore/ChangeLog:10
> +        Add SharedBuffer::copyCFDataNoCreate() which returns CFDataRef if it has one. Refactor
> +        this code out of createCFData().

I don’t like the grammar of the phrase “copy CFData no create”. I’d prefer copyExistingCFData or copyCFDataWithoutCreating.

> Source/WebCore/platform/mac/SharedBufferMac.mm:148
> +    RetainPtr<CFDataRef> cfData = copyCFDataNoCreate();
> +    if (cfData)
> +        return cfData;

Would be nice to put the definition inside the if statement.
Comment 8 Darin Adler 2014-08-11 22:30:46 PDT
Comment on attachment 236390 [details]
Patch2

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

> Source/WebKit2/ChangeLog:13
> +        so that SharedBuffer can take car of the data array case.

typo: "take car"
Comment 9 Darin Adler 2014-08-11 22:31:39 PDT
Comment on attachment 236390 [details]
Patch2

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

>> Source/WebCore/ChangeLog:10
>> +        this code out of createCFData().
> 
> I don’t like the grammar of the phrase “copy CFData no create”. I’d prefer copyExistingCFData or copyCFDataWithoutCreating.

Hmm, why copy? It should just be existingCFData and should not return a RetainPtr.
Comment 10 Pratik Solanki 2014-08-12 11:42:18 PDT
(In reply to comment #9)
> (From update of attachment 236390 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=236390&action=review
> 
> >> Source/WebCore/ChangeLog:10
> >> +        this code out of createCFData().
> > 
> > I don’t like the grammar of the phrase “copy CFData no create”. I’d prefer copyExistingCFData or copyCFDataWithoutCreating.
> 
> Hmm, why copy? It should just be existingCFData and should not return a RetainPtr.

I like this! I'll change it to existingCFData and return a raw pointer.
Comment 11 Pratik Solanki 2014-08-12 15:51:07 PDT
Committed r172502: <http://trac.webkit.org/changeset/172502>