[webkit-dev] JSGlobalData GC collection thread lifetime if webview is recreated without application exit.
Hi All, I have been studying the JS execution and noticed that the JSGlobalData is stored in a static variable and never deleted. I traced even the windows port and noticed one more thing, that the JSGlobalData and the Heap class destructor are never called. As it is static I assume that the JSGlobalData is cleaned up automatically on process exit. I realised that this would in turn have an effect if we delete the webview and recreate it again. The JSGlobalData will still point to the old static var. So now to my question : Is it required to delete JSGlobalData and kill the GC thread if we keep on re-creating the webview again and again without exiting the process? Thanks. --Mayur. -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSGlobalData GC collection thread lifetime if webview is recreated without application exit.
So now to my question : Is it required to delete JSGlobalData and kill the GC thread if we keep on re-creating the webview again and again without exiting the process? No. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG optimizations
Hi, Have you some news about dfg optimisations? what are you planing, what have you now or what is your current work ? Currently we do not have either LICM, or loop peeling, or GCSE. We do have a patch that implements LICM, but we are letting it simmer for now because under the current DFG IR, it is somewhat of a complicated beast. My main concern is just bug tail, due to the various stunts that the current LICM patch has to do to fool the DFG into moving code between basic blocks. We're fixing that by steadily moving the DFG IR towards SSA. Once we finish that, I think we'll implement either LICM or peeling+GCSE based on whatever appears to be the simplest. We already know that LICM is a pure performance win; but on the other hand, GCSE is likely to be more generic. I tend to think that extending our current CSE framework to support some maximally-profitable subset of GCSE will not be terribly difficult. We don't currently have PRE. It's not on my short list of optimizations to implement. But if we wanted to go down that route, it might be interesting to consider something like Van Drunen's GVN-PRE [1]. I have already been thinking about implementing GVN; maybe just going straight for GVN-PRE would turn out to be easy enough. But it goes without saying that GVN alone is a dead-simple optimization compared to Van Drunen's work, and, even according to his performance results, PRE is a *tiny* win over simpler redundancy elimination optimizations. -Filip [1] ftp://ftp.cs.purdue.edu/pub/hosking/papers/a-ssapre.pdf On Mar 25, 2012, at 4:59 PM, Nare Karapetyan wrote: HI! There is a discussion about LICM implementation in DFG in one of previous posts. There it was said that the developers had not decided yet which optimization to do: LICM or loop peeling with global CSE. So is there any progress in this direction? And about CSE, does it include the partial redundancy elimination (PRE)? -- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- next part -- An HTML attachment was scrubbed... URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20120325/a57e47fa/attachment-0001.html -- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev End of webkit-dev Digest, Vol 82, Issue 38 ** ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Importing W3C tests to webkit
At the WebKit contributor's meeting in April, we discussed a process for importing third party tests into the WebKit repository (specifically, from the W3C test repository). I documented the process that we came up with at the meeting on the WebKit wiki, here: http://trac.webkit.org/wiki/ImportingThirdPartyTests It would be great if we could get some feedback on this process. Once we can finalize the details for how this should function, the effort can proceed - scripts can be written to help automate the effort and an actual import of select W3C test suites can be performed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
As I have said in the past, we should just import all tests, and treat non-text, non-ref tests as pixel tests. If we wanted to reduce the number of pixel tests we import, then we should submit those patches to W3C instead of directly submitting them to WebKit. In general, I don't buy the argument that adding more pixel tests incurs more cost than the benefit we get from importing the tests. If that were the case, we can just get rid of the existing pixel tests we have. The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. For script-based tests that print PASS/FAIL, it seems better to just check in *-expected-failure.txt or even -expected.txt files because we'll see PASS/FAIL in the expected tests themselves. - Ryosuke On Wed, May 23, 2012 at 10:26 AM, Jacob Goldstein jac...@adobe.com wrote: At the WebKit contributor's meeting in April, we discussed a process for importing third party tests into the WebKit repository (specifically, from the W3C test repository). I documented the process that we came up with at the meeting on the WebKit wiki, here: http://trac.webkit.org/wiki/ImportingThirdPartyTests It would be great if we could get some feedback on this process. Once we can finalize the details for how this should function, the effort can proceed - scripts can be written to help automate the effort and an actual import of select W3C test suites can be performed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] scrollInToView(true) have different behavior on WebKit and Firefox
Hi, While taking a look into bug 83419 (about fast/transforms/scrollIntoView- transformed.html) I faced with the following render issue: When using Element::scrollInToView(true) on blocking elements that have bigger child elements with margins webkit and Firefox show different results. I attached the html file [1] and the render results on Firefox[2] and WebKit[3] into the bug, so what's the correct result? IMO the Firefox behavior seems right, but before trying to fix anything better to know if a consensus on what is right exists. The scrollInToView spec[4] says: If the align to top flag is set align the top of the border box of the element to be scrolled into view with the top of the scrolling box. [1] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143619 [2] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143620 [3] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143621 [4] http://dev.w3.org/csswg/cssom-view/ Regards, Hugo Parente Lima signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
I agree. If nothing else, getting W3C tests into the WebKit repository will help catch regressions. From: Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org To: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com Cc: WebKit Development webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Importing W3C tests to webkit As I have said in the past, we should just import all tests, and treat non-text, non-ref tests as pixel tests. If we wanted to reduce the number of pixel tests we import, then we should submit those patches to W3C instead of directly submitting them to WebKit. In general, I don't buy the argument that adding more pixel tests incurs more cost than the benefit we get from importing the tests. If that were the case, we can just get rid of the existing pixel tests we have. The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. For script-based tests that print PASS/FAIL, it seems better to just check in *-expected-failure.txt or even -expected.txt files because we'll see PASS/FAIL in the expected tests themselves. - Ryosuke On Wed, May 23, 2012 at 10:26 AM, Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com wrote: At the WebKit contributor's meeting in April, we discussed a process for importing third party tests into the WebKit repository (specifically, from the W3C test repository). I documented the process that we came up with at the meeting on the WebKit wiki, here: http://trac.webkit.org/wiki/ImportingThirdPartyTests It would be great if we could get some feedback on this process. Once we can finalize the details for how this should function, the effort can proceed - scripts can be written to help automate the effort and an actual import of select W3C test suites can be performed. ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa rn...@webkit.org wrote: As I have said in the past, we should just import all tests, and treat non-text, non-ref tests as pixel tests. If we wanted to reduce the number of pixel tests we import, then we should submit those patches to W3C instead of directly submitting them to WebKit. In general, I don't buy the argument that adding more pixel tests incurs more cost than the benefit we get from importing the tests. If that were the case, we can just get rid of the existing pixel tests we have. Not so: if the tests we had had 100% coverage, then importing more tests would buy us nothing, but getting rid of the existing tests would be quite unfortunate. Clearly adding tests incurs some costs and probably provides some benefit; the question is when does the cost exceed the benefit? As I am not against importing more tests per se, I think this only makes sense to evaluate on a case-by-case basis. The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. I'm assuming the above includes the ongoing maintenance cost of keeping pixel tests up to date, as well as the cost at the initial checkin. There is also the fact that the more tests we have, the more tests we have to run, and increasing cycle time by itself is a cost to developer productivity. Of course, it's also potentially the case that we have to update tests from time to time, although this doesn't happen often. Jacob, I gave you a bunch of feedback not long after you published the initial writeup, but it doesn't look like any of that has been incorporated? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
Dirk, my apologies, I was on travel the week you replied and missed your message. I found it and will review / update now. On 5/23/12 1:25 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, May 23, 2012 at 11:56 AM, Ryosuke Niwa rn...@webkit.org wrote: As I have said in the past, we should just import all tests, and treat non-text, non-ref tests as pixel tests. If we wanted to reduce the number of pixel tests we import, then we should submit those patches to W3C instead of directly submitting them to WebKit. In general, I don't buy the argument that adding more pixel tests incurs more cost than the benefit we get from importing the tests. If that were the case, we can just get rid of the existing pixel tests we have. Not so: if the tests we had had 100% coverage, then importing more tests would buy us nothing, but getting rid of the existing tests would be quite unfortunate. Clearly adding tests incurs some costs and probably provides some benefit; the question is when does the cost exceed the benefit? As I am not against importing more tests per se, I think this only makes sense to evaluate on a case-by-case basis. The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. I'm assuming the above includes the ongoing maintenance cost of keeping pixel tests up to date, as well as the cost at the initial checkin. There is also the fact that the more tests we have, the more tests we have to run, and increasing cycle time by itself is a cost to developer productivity. Of course, it's also potentially the case that we have to update tests from time to time, although this doesn't happen often. Jacob, I gave you a bunch of feedback not long after you published the initial writeup, but it doesn't look like any of that has been incorporated? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On Wed, May 23, 2012 at 1:25 PM, Dirk Pranke dpra...@chromium.org wrote: Not so: if the tests we had had 100% coverage, then importing more tests would buy us nothing, but getting rid of the existing tests would be quite unfortunate. We certainly don't have 100% test coverage. Clearly adding tests incurs some costs and probably provides some benefit; the question is when does the cost exceed the benefit? Doing anything incurs some cost. In fact, not adding a test itself incurs a risk cost of potentially taking regressions in the future that could have been caught by the test. As I am not against importing more tests per se, I think this only makes sense to evaluate on a case-by-case basis. Sure. We shouldn't be importing tests that are obviously duplicates of our existing tests. The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. I'm assuming the above includes the ongoing maintenance cost of keeping pixel tests up to date, as well as the cost at the initial checkin. I'm not concerned of those. Once the correct expected result is checked in, it's pretty easy to rebaseline tests per rendering engine changes assuming people who are rebaselining tests know what they're doing. There is also the fact that the more tests we have, the more tests we have to run, and increasing cycle time by itself is a cost to developer productivity. Sure, but I don't think that's a valid argument for not adding tests especially since there is no way for us to mechanically test whether two tests test the same set of features or not (this is an intractable problem even in its limited form and an undecidable one in its most general form). Also, using ref test or pixel test, etc... doesn't change the cycle time significantly so I don't understand what your argument is. Or are you suggesting that non-ref tests are somehow more redundant than ref tests? (please give us why). Of course, it's also potentially the case that we have to update tests from time to time, although this doesn't happen often. Because the current process is broken :) In the ideal world, we would be updating our copy of W3C tests every so often (e.g. every month or so). - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote: The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. I'm assuming the above includes the ongoing maintenance cost of keeping pixel tests up to date, as well as the cost at the initial checkin. I'm not concerned of those. Once the correct expected result is checked in, it's pretty easy to rebaseline tests per rendering engine changes assuming people who are rebaselining tests know what they're doing. You should be concerned; keeping pixel tests up-to-date is clearly a non-zero cost that only the chromium port thus far has been willing to bear, and I suspect that the cost of updating baselines is substantially higher than the cost of the initial review over time (since it's a recurring cost). We only have to ask Emil and Levi what the cost of updating all of the pixel tests were for the subpixel layout test change, or ask the skia guys how many bug fixes they're reluctant to make because of the cost of reviewing literally thousands of images that change inconsequentially for empirical evidence for this. There is also the fact that the more tests we have, the more tests we have to run, and increasing cycle time by itself is a cost to developer productivity. Sure, but I don't think that's a valid argument for not adding tests especially since there is no way for us to mechanically test whether two tests test the same set of features or not (this is an intractable problem even in its limited form and an undecidable one in its most general form). At some point adding more tests will introduce a declining marginal rate of return in finding more bugs; this is a truism of software development, and is why *all* software testing efforts stop at some point (ignoring formal proofs of completeness in model checkers). Either you don't think this is true, or you think this is true and we're just not at that point yet. If you think the latter then we agree, but I don't understand why you are arguing as if you believe the former. To repeat myself, I have never said that we shouldn't ever add more tests, just that we should have a rational process for doing so that includes looking at what overlap we have with the existing tests and making sure that adding more tests delivers value. Since you agree at least that we shouldn't be adding duplicate tests, you clearly agree with this to some degree, so I'm not sure if you and I have any real disagreements or if we're just talking past each other. Also, using ref test or pixel test, etc... doesn't change the cycle time significantly so I don't understand what your argument is. Or are you suggesting that non-ref tests are somehow more redundant than ref tests? (please give us why). I am saying that I believe that adding pixel tests incur more cost on the project than adding ref tests, and since all testing is about cost vs. benefit, you need to be more careful when adding pixel tests. Since we actively discourage people from writing pixel tests in favor of text-only or ref tests, I hardly think this is a controversial stance. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote: The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. I'm assuming the above includes the ongoing maintenance cost of keeping pixel tests up to date, as well as the cost at the initial checkin. I'm not concerned of those. Once the correct expected result is checked in, it's pretty easy to rebaseline tests per rendering engine changes assuming people who are rebaselining tests know what they're doing. You should be concerned; keeping pixel tests up-to-date is clearly a non-zero cost that only the chromium port thus far has been willing to bear, and I suspect that the cost of updating baselines is substantially higher than the cost of the initial review over time (since it's a recurring cost). Are you concerned just about the actual pixel results or also about keeping render tree dumps up to date? We can address the pixel result issue by introducing a new test that dumps its render tree but does not do pixel testing. I think there is a high value to importing standards test suites wholesale, even if they overlap with our existing coverage. Picking and choosing subsets makes things more complicated. If there are significant externalities to adding particular kinds of tests, I would prefer we mitigate those externalities rather than run fewer tests. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On 5/23/12 2:30 PM, Maciej Stachowiak m...@apple.com wrote: On May 23, 2012, at 2:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, May 23, 2012 at 1:41 PM, Ryosuke Niwa rn...@webkit.org wrote: The only sane argument I've heard so far to gate pixel tests is that the correctness of such tests need to be manually inspected, which requires a lot of manual labor and is very error prone. I'm assuming the above includes the ongoing maintenance cost of keeping pixel tests up to date, as well as the cost at the initial checkin. I'm not concerned of those. Once the correct expected result is checked in, it's pretty easy to rebaseline tests per rendering engine changes assuming people who are rebaselining tests know what they're doing. You should be concerned; keeping pixel tests up-to-date is clearly a non-zero cost that only the chromium port thus far has been willing to bear, and I suspect that the cost of updating baselines is substantially higher than the cost of the initial review over time (since it's a recurring cost). Are you concerned just about the actual pixel results or also about keeping render tree dumps up to date? We can address the pixel result issue by introducing a new test that dumps its render tree but does not do pixel testing. I think there is a high value to importing standards test suites wholesale, even if they overlap with our existing coverage. Picking and choosing subsets makes things more complicated. If there are significant externalities to adding particular kinds of tests, I would prefer we mitigate those externalities rather than run fewer tests. As a side note to this discussion, there is talk in the W3C community regarding their test approval process. At the recent working group meetings in Germany the idea was floated to simply approve all tests that are currently waiting for review (and doing this going forward, e.g. no longer requiring approval upon submission). Apparently, not enough people are reviewing tests, and as a result, tests can linger for months (or longer) before ever being looked at. Once browser vendors start implementing features, associated tests will be revisited for that area. This has by no means been decided, but something we should consider if it ultimately does come to fruition. If W3C tests are no longer reviewed, this would mean importing tests without any knowledge of their accuracy - though that will still allow us to catch regressions. Dirk, I've updated the process on the Wiki page with the feedback you provided. I hope I captured it all - I included everything that appeared to have agreement between you and Ryosuke. Feel free to modify it directly if I missed anything, or let me know and I can refine it further. Jacob Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On May 23, 2012, at 3:13 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, May 23, 2012 at 2:30 PM, Maciej Stachowiak m...@apple.com wrote: Are you concerned just about the actual pixel results or also about keeping render tree dumps up to date? Both are more maintenance than a text-only test. In my experience, maintaining pixel tests is more expensive, but I also don't have any experience maintaining a non-pixel-test-running port. There are occasional changes that require rebaselining a very large number of render tree dumps. In my experience, this happens much less often than the frequency at which Chromium ports update pixel results, by several orders of magnitude. We can address the pixel result issue by introducing a new test that dumps its render tree but does not do pixel testing. Yes, it might make sense to do this (although it's not obvious to me how we would do this without modifying the test sources). Maybe we would need to maintain a separate manifest or some other list somewhere to indicate which dirs or tests should include pixel results. The quick and dirty way would be to add a SkipPixel directive (or whatever) to TestExpectations. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Importing W3C tests to webkit
On Wed, May 23, 2012 at 2:59 PM, Jacob Goldstein jac...@adobe.com wrote: As a side note to this discussion, there is talk in the W3C community regarding their test approval process. At the recent working group meetings in Germany the idea was floated to simply approve all tests that are currently waiting for review (and doing this going forward, e.g. no longer requiring approval upon submission). Apparently, not enough people are reviewing tests, and as a result, tests can linger for months (or longer) before ever being looked at. Once browser vendors start implementing features, associated tests will be revisited for that area. This has by no means been decided, but something we should consider if it ultimately does come to fruition. If W3C tests are no longer reviewed, this would mean importing tests without any knowledge of their accuracy - though that will still allow us to catch regressions. Ick :(. I suppose if the test suites are mostly coming from established browser vendors or other trusted sources (who have been running them on their own browsers for a while) this isn't so bad, but it would be nice to see the suites get vetted somehow prior to them getting blessed by the w3c. Levels of approval, or something? Dirk, I've updated the process on the Wiki page with the feedback you provided. I hope I captured it all - I included everything that appeared to have agreement between you and Ryosuke. Feel free to modify it directly if I missed anything, or let me know and I can refine it further. It looks much closer to what I'd like, thanks! I'll probably modify it a bit and/or send you some suggestions offlist for some minor things. The one major issue I still have that I wouldn't want to just add/sneak into the wiki, is that I still don't see much of a discussion for how we identify duplicate tests. The mindset I would prefer would be that, for a given test suite, the person or persons importing the test suite should have to start by identifying which existing tests we have for similar functionality, and produce lists of which existing tests look like they are duplicates and should be remvoed, which tests we have that should be submitted back to the w3c for future inclusion, and which tests are clearly webkit-specific and should be kept but identified as clearly webkit-specific. For example, if we import a flexbox test suite from css3, we should default to removing fast/flexbox (and possibly also ietestcenter/css3/flexbox). [ This is a purely hypothetical example (I know nothing about these test suites). I wish to re-emphasize that we will have to look at these things on a case-by-case basis. ] I have no idea how much work we'd be asking the importer to undertake, but that's kinda the point. If we don't ask the importer to de-dup things, who is realistically going to de-dup them later? What do others thinks, is this too much to ask? If it is, how do we avoid incurring further test debt over time? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
