Re: [webkit-dev] recompilation in dfg
Two bad things could have happened: 1) OSR entry failed. That's rare. You could try to put some logging in prepareOSREntry. 2) The GC decided that it didn't want to keep your code around anymore. We have heuristics for doing this even if your code doesn't OSR exit, and even when the owning function is still live. The reason is that the generated machine code may have pointers to the heap. If those objects are not otherwise live, the GC has to either make them live (which could increase footprint) or kill the DFG code block. It will often do the latter. As Maciej suggests, a bug report would be great. We are always interested in looking at programs where our heuristics fail. -F On Oct 12, 2012, at 6:26 PM, Blake Fiddler wrote: > Hi. > I have some example in which my function recompiling in dfg jit (it's parsing > in second time without OSR exits). > Can you explain me why that happens and in which cases? > > Regards, Blake. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] recompilation in dfg
The best way to find out would be to file a bug at http://bugs.webkit.org/ with a test case demonstrating the problem. - Maciej On Oct 12, 2012, at 6:26 PM, Blake Fiddler wrote: > Hi. > I have some example in which my function recompiling in dfg jit (it's parsing > in second time without OSR exits). > Can you explain me why that happens and in which cases? > > Regards, Blake. > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] recompilation in dfg
Hi. I have some example in which my function recompiling in dfg jit (it's parsing in second time without OSR exits). Can you explain me why that happens and in which cases? Regards, Blake. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak wrote: > > On Oct 11, 2012, at 7:40 AM, Mark Toller wrote: > > >> -Original Message- > >> From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com] > >> > >> On 10/10/2012 10:26 AM, Mark Toller wrote: > >>> What we would like to see initially is Webkit based browsers (Chrome, > >>> Safari, Minibrowser, etc) actually load HbbTV pages instead of asking > >>> the user to download the content - this would indirectly benefit the > >>> end goal of Webkit (to get everyone to support standard W3C/HTML5)... > >> > >> This particular change is just a matter of adding one more displayable > >> mime-type, right? > > > > Almost. I've created a bug and patch for this particular change: > > > > https://bugs.webkit.org/show_bug.cgi?id=99049 > > > > As someone else stated, I think the best approach is to create > > a bug for each change we consider worthwhile, and then they can be > > considered individually. > > I don't think we should take this change or accept this feature in > general. It seems that of those who have spoken up, the WebKit community is > not in favor of this direction. > Even though the specific change in that patch is relatively small, > supporting custom MIME types has significant disadvantages: > > - Creates interoperability issues with other browsers. > - Fragments the web > - Opens us up to further requests to add support for similarly niche MIME > types in the future > > If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it > should be served with text/html MIME type. That would avoid all of these > problems. If a consortium decided to create custom mime types instead, then > they made a mistake and should fix it. In some cases, when the technology > is compelling or there is a wealth of existing content, we live with > arguable errors in the standard. But neither of those considerations > applies here. > > Regards, > Maciej > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > +1. As someone who builds applications specifically for TV producers, I feel that this custom mime type is the first in a series of bad moves. Why doesn't the HBB group form its own W3 style group? I think this is just heading in the wrong direction. rb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixing requestAnimationFrame
Me too. Please don't just remove the prefix - we need a period of time where we support both prefixed and unprefixed. Dean On 12/10/2012, at 6:58 PM, Maciej Stachowiak wrote: > > I agree with this position as well. It seems good to have a transition period > and to gather some data. > > - Maciej > > On Oct 11, 2012, at 9:59 PM, Darin Fisher wrote: > >> I agree with what Adam wrote in >> https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites >> will magically failover to the unprefixed API, we can't know for sure that >> this change won't break sites. We need to give them a chance to update. (I >> don't know if one Chrome release cycle will be enough.) >> >> Why not be conservative here? >> >> -Darin >> >> >> On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen >> wrote: >> I've posted a patch to remove the "webkit" prefix from >> requestAnimationFrame. [1] The question is whether or not to continue to >> support the prefixed version. I propose dropping it for the following >> reasons: >> >> 1. We're changing the callback semantics to match the spec. [2] >> >> 2. IE10 is shipping with this unprefixed. [3] >> >> 3. Toolkits already use the unprefixed version. [4] >> >> 4. The advice on the internet recommends everyone use the polyfill >> technique. [5] >> >> I'm curious what everyone else thinks. >> >> James >> >> [1] https://bugs.webkit.org/show_bug.cgi?id=99116 >> [2] https://bugs.webkit.org/show_bug.cgi?id=66683 >> [3] http://caniuse.com/#feat=requestanimationframe >> [4] https://gist.github.com/1579671 >> [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] x32 support of JavaScriptCore
Thank you Gavin. I have created a bug entry and proposed a patch for MacroAssembler refactoring at https://bugs.webkit.org/show_bug.cgi?id=99154. Also, a bug entry is created to trace the x32 support of JavaScriptCore at https://bugs.webkit.org/show_bug.cgi?id=99153. There you could also find how the code should be (based on the refactoring work) to support x32 in JavaScriptCore. Note that currently the low level interpreter on x32 is not enabled yet but on the plan. Would you like to have a look at them? Thanks much, -Yuqiang -Original Message- From: Gavin Barraclough [mailto:barraclo...@apple.com] Sent: 2012年10月12日 2:22 To: Xian, Yuqiang Cc: WebKit Development Subject: Re: [webkit-dev] x32 support of JavaScriptCore Hi Yuqiang, I think that this could be a good refactoring for the MacroAssembler – to move all ( Ptr->32 / Ptr->64 ) remapping into MacroAssembler.h, introduce a Imm64, rename all the current *Ptr* methods in MacroAssemblerX86_64 to *64*, etc – please feel free to put up patches for this, and cc me. If this is the bulk of your changes, it may not be a problem to upstream support if you'll be prepared to maintain, and if that doesn't work out it should at least reduce the size of your diff. We prefer incremental changes, so please split out any refactoring that will affect all platforms from changes to support x32, these should be landed separately. cheers, G. On Oct 11, 2012, at 1:52 AM, Xian, Yuqiang wrote: > On X32, the size of a pointer or a "long" integer is 4 bytes instead of 8 > bytes on X64, while the register size is still 8 bytes. > > In JavaScriptCore implementation for X64, it assumes that the JSValue size is > same to the pointer size, and thus EncodedJSValue is simply type defined as a > "void*". In the JIT compiler, we also take this assumption and invoke the > same macro assembler interface for both JSValue and pointer operands. So the > primary task for x32 support is to differentiate the operations on pointers > from the operations on JSValues, and let them invoking different macro > assembler interfaces. For example, we now use the interface of "loadPtr" to > load either a pointer or a JSValue, and we need to switch to using "loadPtr" > to load a pointer and some new "load64" interface to load a JSValue. > The major modification I made is to introduce the "*64" interfaces in the > MacroAssembler, make the "*Ptr" interfaces platform dependent implemented > (one for X32 and the other for X64), and go through all the JIT compiler code > to identify which interfaces should be used. > Also, the calling convention needs to be cared. For example on X64 you may > need two registers to pass or return a structure with two pointer size > members, while on X32 those two members are placed in one register. > > Thanks, -Yuqiang > > -Original Message- > From: Zoltan Herczeg [mailto:zherc...@webkit.org] > Sent: 2012年10月11日 15:43 > To: Xian, Yuqiang > Cc: Kenneth Rohde Christiansen; webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] x32 support of JavaScriptCore > > Just out of curiosity, how much code modifications are required? I read > the ABI documentation the link you attached, and "x32" is a regular 64 bit > mode, except it seems to me that the global descriptor table is tweaked to > store the same descriptors for all 4G address spaces, so the upper 32 bit > is basically ignored when you access a memory address. It is called Small > Code Model or something. I suspect the changes in the JIT code are > minimal. > > Regards, > Zoltan > >> Thanks for the suggestions, Kenneth. >> >> I'm refining the code and trying to enable the last major component - the >> low level interpreter for x32. >> Yes it's ideal if we can upstream the code, and as you mentioned, keep >> maintaining it. The buildbot is a good idea while we are still way far >> from it - it requires a mature x32 system which at least supports all of >> the things that a WebKit port depends on. I know there're efforts porting >> Gentoo and Fedora to x32 - we may depend on each other. >> >> Currently I'm testing the JSC shell only. Though I use the EFL port, I >> eliminated most of the unnecessary dependencies on EFL libraries to run >> the JSC shell, so that I don't need to put efforts on compiling and >> enabling those dependencies for x32 at current stage. >> >> Thanks, -Yuqiang >> >> -Original Message- >> From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] >> Sent: 2012年10月11日 5:51 >> To: Xian, Yuqiang >> Cc: webkit-dev@lists.webkit.org >> Subject: Re: [webkit-dev] x32 support of JavaScriptCore >> >> Hi, >> >> I don't think another branch on webkit.org will help you much; then >> you can as well have a branch anywhere. >> >> If you want this code to be well tested and maintained, you need to >> get it upstream (through all the review process) and promise that you >> have resources to keep maintaining it. It will also be an adva
[webkit-dev] Fwd: Transformations precision: double -> float
(again from corrected account) Originally To: Gabor Rapcsanyi , CC: Mike Reed Do you have particular bottleneck functions that you have reason to believe would benefit from ARM SIMD optimizations? Under what workloads, and how much benefit? We've see a few ridiculously expensive transform functions in WebKit that my colleagues in Chapel Hill might be able to recall, but usually it's the rendering engines that are hot, not WebKit itself. We have seen places where double math appears to be absolutely required for correctness: matrix inversion and path convexity testing; there are some other areas we're experimenting with that seem to require it as well. You'd probably need to survey WebKit for stability (or just hack in doubles and run layout tests) to see how many other places will break if you throw away the extra precision. The rest of Chromium's renderer (Skia) uses float, and we've deployed SSE/NEON and played with float vs double quite a bit there. The float->double conversion at the WebKit/Skia boundary doesn't seem to be too much of a drag, but doing it in any sort of inner loop can really kill performance. Meanwhile, there are a lot of places where switching from ARM assembly to NEON in the renderer hasn't given us as much win as we'd hoped for, which is why the question "how much benefit?" seems important to answer before spending too much time polishing a set of typedefs. Tom ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Transformations precision: double -> float
Yes I agree that we need to do some measures to see the benefits of floats. But it's not just about the performance and memory gain of the floats, I would like to make ARM SIMD optimizations for the transformation functions to fasten up them, but ARM NEON technology only works with floats that's why I want to change the doubles. I would prefer a typedef solution to make this configurable as Ryosuke said, and then the ports could chose whether they need floats, doubles or long doubles. - Gabor On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi wrote: That was a long time ago and there were no objections Unless there's something in the spec requiring double precision it makes sense to move away from double precision throughout WebKit. I’m a little concerned about this. The programming interface to the graphics system on OS X uses doubles, so it’s likely we’ll be introducing float to double conversions for at least that platform if we change things inside WebKit that are currently doubles to float en masse. Similarly, the native data type for numbers in JavaScript is double. So any time we are passing a number from JavaScript to WebKit it’s likely that additional double to float conversions will be required as we change internals to use doubles instead of floats. On the other hand, there may also be performance boost or memory gains from using float instead of double. If we do make this change, I think we need to do performance testing as we do so, perhaps on more than one platform, to see if these changes are leading to benefits or not. I also think that “we should always use float unless a spec mandates double” is probably not the right rule of thumb. There are many factors other than “a spec” at play here. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixing requestAnimationFrame
I agree with this position as well. It seems good to have a transition period and to gather some data. - Maciej On Oct 11, 2012, at 9:59 PM, Darin Fisher wrote: > I agree with what Adam wrote in > https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites > will magically failover to the unprefixed API, we can't know for sure that > this change won't break sites. We need to give them a chance to update. (I > don't know if one Chrome release cycle will be enough.) > > Why not be conservative here? > > -Darin > > > On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen wrote: > I've posted a patch to remove the "webkit" prefix from requestAnimationFrame. > [1] The question is whether or not to continue to support the prefixed > version. I propose dropping it for the following reasons: > > 1. We're changing the callback semantics to match the spec. [2] > > 2. IE10 is shipping with this unprefixed. [3] > > 3. Toolkits already use the unprefixed version. [4] > > 4. The advice on the internet recommends everyone use the polyfill technique. > [5] > > I'm curious what everyone else thinks. > > James > > [1] https://bugs.webkit.org/show_bug.cgi?id=99116 > [2] https://bugs.webkit.org/show_bug.cgi?id=66683 > [3] http://caniuse.com/#feat=requestanimationframe > [4] https://gist.github.com/1579671 > [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
