<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Avoid evicting link preload resources when parsing is done."
href="https://bugs.webkit.org/show_bug.cgi?id=167415#c21">Comment # 21</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Avoid evicting link preload resources when parsing is done."
href="https://bugs.webkit.org/show_bug.cgi?id=167415">bug 167415</a>
from <span class="vcard"><a class="email" href="mailto:yoav@yoav.ws" title="Yoav Weiss <yoav@yoav.ws>"> <span class="fn">Yoav Weiss</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=167415#c20">comment #20</a>)
<span class="quote">> Comment on <span class=""><a href="attachment.cgi?id=299837&action=diff" name="attach_299837" title="Patch">attachment 299837</a> <a href="attachment.cgi?id=299837&action=edit" title="Patch">[details]</a></span>
> Patch
>
> I guess an alternative would be to restrict m_preloads to speculative
> preloads only.
> Can we do that?</span >
We probably could, but that would probably mean duplicating the existing mechanisms that relate to m_preloads, or generalize them so that they can be applied to two separate lists. Do you think such a separation would be valuable enough to justify that?
<span class="quote">> Also, if we do not fully clean m_preloads at onload time, won't we keep
> references to these resources?</span >
We fully clear m_preloads when CachedResourceLoader is terminated, so (IIUC) when the document is detached.
<span class="quote">> If so, we might not be able to reclaim memory on these, even if MemoryCache
> is asked to do so.</span >
That's deliberate, as these resources might be used after onload (e.g. by scripts injecting corresponding DOM nodes that need them)
I'm planning to introduce a warning mechanism for unused preloads (probably at 3 seconds after onload). If we want to reclaim memory for these resources before the document detaches, that might be a good point to introduce clearing mechanism for them.
<span class="quote">>
> View in context:
> <a href="https://bugs.webkit.org/attachment.cgi?id=299837&action=review">https://bugs.webkit.org/attachment.cgi?id=299837&action=review</a>
>
> > Source/WebCore/ChangeLog:14
> > + being cleared), said issue is also fixed by clearing previousely preloaded resources if an invalid link preload is later detected.
>
> What happens if a speculative preload is scheduled first and a link preload
> on the same resource happens after.
> Shouldn't the speculative preload be marked as link preload?</span >
I should probably add handling for that scenario for correctness sake, even if I'm not particularly worried about it.
I think such a scenario would be relatively rare, and even if it happens, clearPreloads(ClearSpeculativePreloads) won't evict this resource from MemoryCache, as it would be referenced by the time clearPreloads is first called.
<span class="quote">>
> > Source/WebCore/loader/cache/CachedResourceLoader.cpp:870
> > + resource->setLinkPreload();
>
> This should be done in CachedResource constructor.</span >
OK
<span class="quote">> Maybe we should in the future make CachedResource have a
> CachedResourceRequest member.</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>