Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl
Thanks for the heads up, Anders I've created a bug for this, https://bugs.webkit.org/show_bug.cgi?id=122207 On Wed, Oct 2, 2013 at 3:19 AM, Anders Carlsson wrote: > Hello, > > I just wanted to let everyone know that we (Apple) are moving away from > DrawingAreaImpl and always using our tiled drawing area. Longer term we’d > like to remove DrawingAreaImpl completely since it was designed back when > we didn’t run in accelerated compositing mode all the time. > > It’s my understanding that all the other non-mac ports use coordinated > graphics now, and so the logical step would be to create a special > DrawingArea subclass for coordinated graphics and move the relevant code > there. That’d allow us to remove DrawingAreaImpl and LayerTreeHost. > > I’d be more than happy to review any patches to do this, and answer any > questions. > > Thanks, > - Anders > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
02.10.2013, 03:18, "Zoltan Horvath" : > On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen wrote: >>> So are you proposing to use the system allocator on Windows? >> >> I’m proposing a two step process: >> >> (1) Use the system allocator on Windows (and GTK). >> (2) If a port maintainer cares to optimize a given port, without too much >> disruption to mainline code, they may do so. >> >> FWIW, If I were conducting (2) for Windows, malloc would be pretty far down >> the list of things I started porting. >> >>> The current malloc logic has been the source of a number of mysterious >>> crashes on Windows, so reverting to the system allocator might be a good >>> thing for stability. I don’t know what the potential performance >>> ramifications would be. >> >> Yes, I’ve heard that on other platforms as well. > > This usually happens because the allocation/free mismatches. (In cases such > as memory allocated by TCmalloc via the FastMalloc interface (fastMalloc, > fastNewMalloc) and tried to be freed by the system free.) Out of curiosity, what's wrong with linking whole application using WebKit against tcmalloc or some other malloc implementation? This way it's possible to use optimized allocator without any source changes, and malloc/free mismatch cannot happen. Why FastMalloc API was needed at all? -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reference count leak with InBandTextTracks?
Thanks Jer and Brendan for your explanations.
De : Jer Noble [mailto:jer.no...@apple.com]
Envoyé : mardi 1 octobre 2013 17:47
À : Benjamin Dupont (bedupont)
Cc : webkit-dev@lists.webkit.org
Objet : Re: [webkit-dev] Reference count leak with InBandTextTracks?
On Oct 1, 2013, at 2:48 AM, Benjamin Dupont (bedupont)
mailto:bedup...@cisco.com>> wrote:
Hi all,
I am currently working on the InbandTextTracks in webkit and I am trying to
understand how the memory is released.
When we launch the track-in-band.html layout test, two in-band text tracks have
been created and added, the corresponding RefPtr has a refCount equals to three.
1. Why are there 3 owners for each in-band text track? Is there an hidden cache
mechanism?
The tracks are being referenced by the JavaScript running in the test page.
After this test, if we load another page, the player is destroyed and the
clearTextTracks method is called.
In my understanding, the player should be the only owner of in-band text tracks
and thus after the clearTextTracks method is called, the ref count should be
decreased to 0 and the in-band text track object should be deleted.
Your understanding is incorrect. Each track is also referenced by the
JSTextTrack wrapper created when referencing videoElement.textTracks[].
Furthermore, those wrappers are stored off as variables inbandTrack{1,2,3,4} in
the global context, so they won't be destroyed by GC until the window object is
destroyed
In fact, after the clearTextTracks method the ref count isn't equals to 0 thus
the in-band text track object isn't deleted.
This text track object is deleted when the clear memory cache is called.
2. Is it a normal behavior? If yes, what is the interest to use smart pointer?
Yes.
3. How does the clear memory cache know that this ref pointer (with a ref count
!= 0) can be released?
This is precisely the point of using a smart pointer; since the track is still
being referenced, it won't be deleted until that refcount drops to 0.
-Jer
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
Hi Geoffrey, On Wed 02 Oct 2013 00:11, Geoffrey Garen writes: > There are two problems with the current OSAllocator POSIX implementation: > > (1) It uses mmap, which doesn’t support aligned allocation. To get > aligned allocation, POSIX double-allocates all virtual memory. That is > 2X too much. So, we need to find a variation on mmap that supports an > alignment constraint. This doesn't exist on POSIX, as you probably know. posix_memalign doesn't have the zeroing characteristics of anonymous mmap, and is otherwise a terrible interface. Darwin-like vm_map and friends would be nicer. However, given the constraints, what's the problem with the mmap strategy? Sure, you have more page tables on the kernel side, but mmap'd memory that is never touched is never resident in a process. I verified this a few months back when troubleshooting some memory-related issues. > (2) POSIX uses MADV_FREE, MADV_DONTNEED, and/or MADV_WILLNEED. I don’t > think anybody has ever verified that these APIs do what we want. In my > experience, they usually don’t. So, we need to find a variation on these > APIs that works and is fast. I've looked into it. The MADV_WILLNEED is useless -- it does nothing on anonymous pages, returns -EINVAL, but is harmless also. The MADV_DONTNEED dance does work though, properly paging out memory and lazily providing fresh zeroed pages should the memory be paged in again. > We need somebody to resolve these issues, otherwise our memory > footprint will be unacceptably high, and/or our VM operations will be > unacceptably slow. There is no memory footprint problem caused by mmap here -- to my knowledge. I don't know how to profile the VM overhead, though. I will agree that OSAllocatorPosix.cpp is exceptionally ugly ;), but it does seem to do its job within reasonable performance constraints. Regards, Andy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes in QtWebKit development
On Tuesday 01 October 2013, Oliver Hunt wrote: > > having helped as far as we could. > > But why should webkit have _any_ burden when Qt itself cares so little > about QtWebKit that it is happy to have qtisms that were ostensibly > necessary for performance, etc removed? > So if we try minimize the burden to the project it is proof we don't care about the burden we have on the project? You are really grasping at straws here. > I don’t believe WebKit should be taking _any_ burden for a port that is > primarily focused on a completely separate fork in an unrelated tree. > > So could you please say whether the QtWebKit plan going forward is option 1 > or option 2. > I believe that is a rhetorical question at this point. We will be disabling the Qt bots and start moving the port out today. Feel free to start removing Qt specific code as soon as the bots are out. I would like to request that you leave the Qt specific bugs in bugs.webkit.org open for the time being until they have been evaluated and closed or migrated. Thank you `Allan Jensen ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev wrote: > Out of curiosity, what's wrong with linking whole application using WebKit > against tcmalloc or some other malloc implementation? There are a lot of things wrong with that. Most of them depend on the platform. On Mac, for example, WebKit is a framework. Linking apps using WebKit against a different malloc implementation would have no effect on WebKit’s memory allocation. Further, doing this would create allocator mismatch problems for any memory allocated by WebKit but freed by the application or vice versa. There are many other problems with this approach on Mac. Another one is that there are at least thousands of apps currently using WebKit on Mac, maybe tens of thousands (hundreds of thousands, at least, on iOS), and so if this is something the app developer has to do, there are a lot of people to reach. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl
On Oct 1, 2013, at 11:29 PM, Sergio Villar Senin wrote: > On 02/10/13 03:19, Anders Carlsson wrote: >> Hello, >> >> I just wanted to let everyone know that we (Apple) are moving away from >> DrawingAreaImpl and always using our tiled drawing area. Longer term we’d >> like to remove DrawingAreaImpl completely since it was designed back when we >> didn’t run in accelerated compositing mode all the time. >> >> It’s my understanding that all the other non-mac ports use coordinated >> graphics now, and so the logical step would be to create a special >> DrawingArea subclass for coordinated graphics and move the relevant code >> there. That’d allow us to remove DrawingAreaImpl and LayerTreeHost. > > GTK is not using coordinated graphics, we do WebProcess compositing. I see. Are you ever not in accelerated composited mode? - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl
Hi Anders, On Oct 1, 2013, at 6:19 PM, Anders Carlsson wrote: > I just wanted to let everyone know that we (Apple) are moving away from > DrawingAreaImpl and always using our tiled drawing area. Longer term we’d > like to remove DrawingAreaImpl completely since it was designed back when we > didn’t run in accelerated compositing mode all the time. I believe that this only effects WebKit2, correct? If so, this will have no impact on the Windows port or the WinCairo port. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl
On 02/10/13 18:49, Anders Carlsson wrote: > > On Oct 1, 2013, at 11:29 PM, Sergio Villar Senin wrote: > >> On 02/10/13 03:19, Anders Carlsson wrote: >>> Hello, >>> >>> I just wanted to let everyone know that we (Apple) are moving away from >>> DrawingAreaImpl and always using our tiled drawing area. Longer term we’d >>> like to remove DrawingAreaImpl completely since it was designed back when >>> we didn’t run in accelerated compositing mode all the time. >>> >>> It’s my understanding that all the other non-mac ports use coordinated >>> graphics now, and so the logical step would be to create a special >>> DrawingArea subclass for coordinated graphics and move the relevant code >>> there. That’d allow us to remove DrawingAreaImpl and LayerTreeHost. >> >> GTK is not using coordinated graphics, we do WebProcess compositing. > > I see. Are you ever not in accelerated composited mode? I think Martin Robinson is the one to ask here but AFAIK we're always in AC mode unless some error occurs, like if we're unable to create the GL context. Oh, and I think AC is not working either when running WK2 in Wayland. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 2, 2013, at 1:17 AM, Konstantin Tokarev wrote: > > 02.10.2013, 03:18, "Zoltan Horvath" : >> On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen wrote: So are you proposing to use the system allocator on Windows? >>> >>> I’m proposing a two step process: >>> >>> (1) Use the system allocator on Windows (and GTK). >>> (2) If a port maintainer cares to optimize a given port, without too much >>> disruption to mainline code, they may do so. >>> >>> FWIW, If I were conducting (2) for Windows, malloc would be pretty far down >>> the list of things I started porting. >>> The current malloc logic has been the source of a number of mysterious crashes on Windows, so reverting to the system allocator might be a good thing for stability. I don’t know what the potential performance ramifications would be. >>> >>> Yes, I’ve heard that on other platforms as well. >> >> This usually happens because the allocation/free mismatches. (In cases such >> as memory allocated by TCmalloc via the FastMalloc interface (fastMalloc, >> fastNewMalloc) and tried to be freed by the system free.) > > Out of curiosity, what's wrong with linking whole application using WebKit > against tcmalloc or some other malloc implementation? This way it's possible > to use optimized allocator without any source changes, and malloc/free > mismatch cannot happen. Why FastMalloc API was needed at all? We couldn't find a clean way to do this on Mac because some low-level frameworks make use of specific obscure features of the system allocator. But it may be viable on other platforms. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl
On Wed, Oct 02, 2013 at 09:49:23AM -0700, Anders Carlsson wrote: > > On Oct 1, 2013, at 11:29 PM, Sergio Villar Senin wrote: > > > On 02/10/13 03:19, Anders Carlsson wrote: > >> Hello, > >> > >> I just wanted to let everyone know that we (Apple) are moving away from > >> DrawingAreaImpl and always using our tiled drawing area. Longer term > >> we’d like to remove DrawingAreaImpl completely since it was designed > >> back when we didn’t run in accelerated compositing mode all the time. > >> > >> It’s my understanding that all the other non-mac ports use coordinated > >> graphics now, and so the logical step would be to create a special > >> DrawingArea subclass for coordinated graphics and move the relevant > >> code there. That’d allow us to remove DrawingAreaImpl and > >> LayerTreeHost. > > > > GTK is not using coordinated graphics, we do WebProcess compositing. > > I see. Are you ever not in accelerated composited mode? > Yes, we do enter accelerated composited mode when required, it is not activated all the time. I did not check that code in quite some time but we had planned to try a tiled solution at some point, we just did not have the time to do it up until now, your proposal is a good excuse to push the task. Regarding activating accelerated compositing all the time we will have to check if we have any users that would care about it, considering this is not going to happen tomorrow we can start with work and on the process check if we should add something. Please add me to any of the bugs you open and I'll try to check the code to help with that. Thanks for the heads up. Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 2, 2013, at 2:41 AM, Andy Wingo wrote: > >> We need somebody to resolve these issues, otherwise our memory >> footprint will be unacceptably high, and/or our VM operations will be >> unacceptably slow. > > There is no memory footprint problem caused by mmap here -- to my > knowledge. I don't know how to profile the VM overhead, though. It's easy to fix the VM overhead by unmapping the extra at either end, if running out of address space is a real risk. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa wrote: > On Tue, Oct 1, 2013 at 4:53 PM, James Craig wrote: >> >> Follow-up question: Since this hasn’t made it into the CSS4 spec yet, >> should we temporarily use “-webkit-alt” for the property name? I know there >> has been a push to move away from vendor prefixes lately, so if there are no >> objections, I propose we use the unprefixed version. > > > I think that's what Mozilla and Google are doing but I don't think we > necessary have to follow the suit. FYI, because IMO this is an important clarification - Mozilla and Google use unprefixed versions only *behind a (runtime) flag*, until the spec is stable. That way experimental features are not exposed to the web at large until it is unlikely that the spec will change, to avoid cross-browser compatibility risks. -christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
> However, given the constraints, what's the problem with the mmap > strategy? Sure, you have more page tables on the kernel side, but > mmap'd memory that is never touched is never resident in a process. I > verified this a few months back when troubleshooting some memory-related > issues. Okeedokee. Can you write up this patch for OSAllocator? > >> (2) POSIX uses MADV_FREE, MADV_DONTNEED, and/or MADV_WILLNEED. I don’t >> think anybody has ever verified that these APIs do what we want. In my >> experience, they usually don’t. So, we need to find a variation on these >> APIs that works and is fast. > > I've looked into it. The MADV_WILLNEED is useless -- it does nothing on > anonymous pages, returns -EINVAL, but is harmless also. The > MADV_DONTNEED dance does work though, properly paging out memory and > lazily providing fresh zeroed pages should the memory be paged in again. The API we want shouldn’t zero the pages or require a page fault right away. It should only zero the pages if they end up being used by the rest of the system. In the normal case, it should return the pages to use intact. Otherwise, it will be too slow, and we’ll have to jump through hoops to avoid using the API very much, which confuses the design. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
