<div class="gmail_quote">On Wed, Sep 16, 2009 at 10:57 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Sep 16, 2009, at 10:33 PM, Darin Fisher wrote:</div><br></div><blockquote type="cite"><br><br><div class="gmail_quote"><div class="im">On Wed, Sep 16, 2009 at 9:59 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"> <div style="word-wrap:break-word">
<br><div><div class="im"><div><div>On Sep 16, 2009, at 4:49 PM, Darin Fisher wrote:</div><br></div></div><div class="im"><div><font color="#006312"><br></font><blockquote type="cite"><div class="gmail_quote"> <div><br></div>
<div>Counting work instead of time is much more robust. The getTime call counts is a measure of work, albeit approximate.</div></div></blockquote> <div><br></div></div><div>The way JavaScriptCore execution time limit works is that the clock doesn't start ticking until JS execution begins. So it's unlikely that a full timeout cycle will occur while the process is swapped out or paused, since the clock won't start running until the process is actually executing JS. And the actual timeout check is only done occasionally (every N loop back edges or function calls, for some value of N). So even if there's a context switch in the middle of JS execution, it's unlikely that JS processing will be terminated immediately upon return. So maybe a different solution is appropriate for JavaScriptCore than V8.</div>
<div><br></div></div></div></div></blockquote><div class="im"><div><br></div><div>Consider what happens if during JS execution garbage collection runs. That could cause portions of the VM to be swapped into RAM, which could cause significant wall clock delay. Do you discount time spent in GC?</div>
</div></div></blockquote><div><br></div><div>We don't exclude time spent in GC - slow is slow. But in practice we haven't seen the scenario you describe come up under similar circumstances.</div><div class="im"><br>
</div></div></div></blockquote><div><br></div><div>This may be a bigger factor for Chrome since it is not uncommon for the renderer associated with a background tab to be swapped out. If you just click the close button on a background tab, it is not uncommon for it to require some expensive paging :-(</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>To help us decide whether (and how) to tackle this for non-V8 ports of WebKit, can the Chrome team share the data they have on the following:</div> <div><br></div><div>(1) Frequency of pages doing a busy loop in an unload handler. I've heard it's common but no specific data.</div>
<div>(2) A few examples of URLs to pages that do this, so we can study what they are doing and why.</div> <div>(3) Frequency of a date-based loop being used to implement the busy loop.</div><div>(4) Average additional delay imposed by unload busy loops.</div>
<div>(5) Proportion of sites that use busy looping in unload solely for link tracking and not for any other purpose. </div> <div><br></div></div></blockquote><div><br></div><div>You can find links to example sites in the Chromium bug report:</div>
<div><a href="http://code.google.com/p/chromium/issues/detail?id=7823" target="_blank">http://code.google.com/p/chromium/issues/detail?id=7823</a></div> <div><br></div><div>The bug contains some distilled data.</div></div>
</blockquote><div><br></div></div><div>I found a couple of URLs (which addresses #2) but I couldn't easily find the other data I asked about. Will I find it if I carefully read all 80 comments on that bug, or should I assume it's not available?</div>
<div class="im"><br></div></div></div></blockquote><div><br></div><div>I'm not sure if everything you are looking for is spelled out in the bug. Comment #46 has details for one such advertiser. John may have some more distilled data.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>By the way, the issue is not with trouble sites but with trouble ad networks and/or producers. I believe the web sites are just victims here.</div> <div><br></div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div></div><div>The reason I'm interested in (1)-(4) is to determine if doing nothing is really worse than doing something hackish, as suggested by Adam.</div> <div><br></div><div>The reason I'm interested in (5) is to determine if <a ping> is an adequate replacement. I think if we break existing techniques, we need to give authors a replacement. unload fires when the user leaves the page in any way whatsoever, including closing the window or typing in the location field. So sites could use I/O in unload plus a busy loop to track the amount of time the user spent on the page, or to save state. If sites are doing that, then <a ping> won't be an adequate replacement, so we'll have to do something like Adam's suggestion to guarantee completion of I/O that is initiated in the unload handler. The reason I think it's possible sites care about more than just link tracking is that if that's all they care about, they could just use redirect links, and get a better user experience today than busy looping in unload. If sites are not using redirects for link tracking today, why would they use <a ping> in the future?</div>
<div><br></div></div></blockquote><div><br></div><div>The reason why I don't think they are using it for critical data is because they have a timeout. If they were trying to persist critical data then they would just use a synchronous XHR. In this case, they are trying to increase the probability of successfully sending a ping by giving themselves a few 100 ms.</div>
</div></blockquote></div></div><br><div>I'm not saying it's necessarily critical data, just that I suspect they may want to detect when the user leaves the page for a reason other than a link, and therefore may not be satisfied with <a ping>. If they only care about link tracking, why don't they just convert links to redirects?</div>
<div><br></div></div></blockquote><div><br></div><div>See my follow-up email to the one you are replying to.</div><div><br></div><div>-Darin </div></div>