Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On Mon, Sep 30, 2013 at 10:56 PM, James Craig jcr...@apple.com wrote: Did you realize you sent this off-list? Keeping my reply off-list, too. Oops, I must have pressed the wrong button. On Sep 30, 2013, at 10:42 PM, Ryosuke Niwa rn...@webkit.org wrote: Are you going to add a build flag for this feature? For the feature detection purposes, it seems desirable not to build this feature on platforms/ports where the property value is not properly exposed to AT. Or will your implementation work on all ports that has accessibility support? I expect this to work on all ports that include accessibility support. The end result for the platform accessibility API is that it will expose a different string of text, where it’s already exposing some text. Not anything challenging for a platform API. Excellent! Thanks for the clarification. - R. Niwa ___ 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 Monday 30 September 2013, Oliver Hunt wrote: On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: Some of this is exactly the reason we want to keep Qt WebKit alive. It may never be possible to fully replace Qt WebKit with anything Blink/Chromium based. I really don’t understand this, there are only two options: 1. Qt Webkit is critical to you and you want to support and maintain it, and do all the work necessary for that; or 2. Qt WebKit is not critical, and so you could simply branch and have a permanent stable release platform similar to what the S60 port did years ago. Currently you seem to be arguing for a third option, wherein all of the WebKit developers need to deal with your port, and be hamstrung by the numerous invasive Qt-isms scattered throughout the codebase, for a port that isn’t considered critical to its own platform. Actually I am arguing we should get rid of most of the invasive Qt'ism unless they are really required for Qt WebKit to even work. Many of them were only necessary due to having to support so many platforms. With a more narrow focus we can hopefully get rid of 90% of the burden. If it turns out not to be possible in the end, we can always leave after having helped as far as we could. Best regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Reference count leak with InBandTextTracks?
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? 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. 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? 3. How does the clear memory cache know that this ref pointer (with a ref count != 0) can be released? Thanks in advance for your explanations, Regards, Benjamin Dupont. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes in QtWebKit development
To me the most invasive Qtism is qmake. When can we get rid of that? -Fil On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Monday 30 September 2013, Oliver Hunt wrote: On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: Some of this is exactly the reason we want to keep Qt WebKit alive. It may never be possible to fully replace Qt WebKit with anything Blink/Chromium based. I really don’t understand this, there are only two options: 1. Qt Webkit is critical to you and you want to support and maintain it, and do all the work necessary for that; or 2. Qt WebKit is not critical, and so you could simply branch and have a permanent stable release platform similar to what the S60 port did years ago. Currently you seem to be arguing for a third option, wherein all of the WebKit developers need to deal with your port, and be hamstrung by the numerous invasive Qt-isms scattered throughout the codebase, for a port that isn’t considered critical to its own platform. Actually I am arguing we should get rid of most of the invasive Qt'ism unless they are really required for Qt WebKit to even work. Many of them were only necessary due to having to support so many platforms. With a more narrow focus we can hopefully get rid of 90% of the burden. If it turns out not to be possible in the end, we can always leave after having helped as far as we could. Best regards `Allan ___ 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] Reference count leak with InBandTextTracks?
I've been working on the GStreamer version of in-band text tracks, but I haven't looked at the details of how RefPtr works. My guess is that JavaScript is holding those extra refs, and the clear memory cache forces a JS garbage collect. On 10/01/2013 03:48 AM, Benjamin Dupont (bedupont) 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? 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. 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? 3. How does the clear memory cache know that this ref pointer (with a ref count != 0) can be released? Thanks in advance for your explanations, Regards, Benjamin Dupont. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: OpenPGP digital signature ___ 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?
On Oct 1, 2013, at 2:48 AM, Benjamin Dupont (bedupont) 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
smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Mon, Sep 30, 2013 at 7:41 PM, Zoltan Horvath zol...@webkit.org wrote: Based on a 2.5-year-old measurement (http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on the Qt-port, the page loading on the Methanol test suite was 5% faster (avg) with TCmalloc than the default system allocator on Linux. The performance results of the SunSpider suite was similar for both allocators. The memory consumption was always lower with the default os allocator. A 5% regression in page load performance seems pretty serious. --Martin ___ 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 Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Monday 30 September 2013, Oliver Hunt wrote: On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: Some of this is exactly the reason we want to keep Qt WebKit alive. It may never be possible to fully replace Qt WebKit with anything Blink/Chromium based. I really don’t understand this, there are only two options: 1. Qt Webkit is critical to you and you want to support and maintain it, and do all the work necessary for that; or 2. Qt WebKit is not critical, and so you could simply branch and have a permanent stable release platform similar to what the S60 port did years ago. Currently you seem to be arguing for a third option, wherein all of the WebKit developers need to deal with your port, and be hamstrung by the numerous invasive Qt-isms scattered throughout the codebase, for a port that isn’t considered critical to its own platform. Actually I am arguing we should get rid of most of the invasive Qt'ism unless they are really required for Qt WebKit to even work. Many of them were only necessary due to having to support so many platforms. With a more narrow focus we can hopefully get rid of 90% of the burden. If it turns out not to be possible in the end, we can always leave after 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? My reading of that is that you are more willing to have the quality of QtWebKit deteriorate than to simply fork off a final high quality stable branch. 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. —Oliver Best regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] EDITBUGS permission?
Is this the right mailing list to ask for EDITBUGS permission? I have 16 accepted patches, and it would be nice if I could assign bugs to myself. http://trac.webkit.org/search?q=Patch+by+Brendan+Long My email on the WebKit bug tracker is: b.l...@cablelabs.com signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
A 5% regression in page load performance seems pretty serious. I’m assuming you’re considering the GTK port here, and not the end-of-life Qt port. Are you up for some engineering work to adopt a better malloc for GTK? Here’s a rough task list: (1) Define a canonical GTK platform we’ll use for performance measurement. (2) Measure FastMalloc on/off on that platform. Assuming FastMalloc is a significant improvement: (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by global operator new/delete in WebCore+JavaScriptCore. (1a) Either build the API layer as a separate library from WebCore+JavaScriptCore, (1b) or specifically annotate each object at the API library with a per-class operator new / operator delete. (2) Find a fast secure random number API on the canonical GTK platform. (3) Find a fast thread-specific data API on the canonical GTK platform. If you take on these tasks, I’m happy to take on the larger task of providing a fast malloc for GTK WebKit. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
Here’s a rough task list: (1) Define a canonical GTK platform we’ll use for performance measurement. (2) Measure FastMalloc on/off on that platform. Assuming FastMalloc is a significant improvement: (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by global operator new/delete in WebCore+JavaScriptCore. (1a) Either build the API layer as a separate library from WebCore+JavaScriptCore, (1b) or specifically annotate each object at the API library with a per-class operator new / operator delete. (2) Find a fast secure random number API on the canonical GTK platform. (3) Find a fast thread-specific data API on the canonical GTK platform. (4) Find a fast API for aligned virtual memory allocation. (5) Find a fast API for committing / decommitting physical memory without releasing virtual memory pages. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 1, 2013, at 11:56 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen gga...@apple.com wrote: A 5% regression in page load performance seems pretty serious. I’m assuming you’re considering the GTK port here, and not the end-of-life Qt port. Are you up for some engineering work to adopt a better malloc for GTK? I appreciate your offer! Here’s a rough task list: (1) Define a canonical GTK platform we’ll use for performance measurement. Perhaps the University of Szeged team has some insight into what platforms they used for comparing allocator performance. (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by global operator new/delete in WebCore+JavaScriptCore. (1a) Either build the API layer as a separate library from WebCore+JavaScriptCore, (1b) or specifically annotate each object at the API library with a per-class operator new / operator delete. I don't think this should be a problem. Currently all allocations of API-level objects happen with the GLib slab allocator (or system malloc/free, given the right environment arguments). (2) Find a fast secure random number API on the canonical GTK platform. I can look into this. WTF has a custom implementation of arc4random(), i suspect most current Gtk host environments have a native one as well (s_rand on windows is terribly slow, but like i said, WTF has its own secure generator that will seed appropriately) (3) Find a fast thread-specific data API on the canonical GTK platform. Threading for GTK+ on non-Mac/non-Windows platforms is essentially pthreads. It probably wouldn't be a lot of work to defer to Windows and Mac implementations on those platforms. I recall linux having fast thread locals, as does windows. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Sep 30, 2013, at 2:48 PM, Geoffrey Garen gga...@apple.com wrote: Hi folks. I’m planning to remove our years-out-of-date port of TCMalloc, and replace it with something that takes maximum advantage of Mac and iOS virtual memory, threading, and security APIs. I've heard that TCMalloc has caused some problems for non-Mac, non-iOS ports in the past. So, if you maintain a port, this change might make things simpler for you. Are there any ports whose built-in malloc implementations are slow enough that they can’t get by without TCMalloc? Apple's Windows port uses FastMalloc and the last measurements we took show it to be a large performance gain over the default Windows malloc implementation. While this port is only used by iTunes these days, we still would not want to regress its performance. Can the new allocator be made to work with Windows? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Tue, Oct 1, 2013 at 11:34 AM, Geoffrey Garen gga...@apple.com wrote: (4) Find a fast API for aligned virtual memory allocation. (5) Find a fast API for committing / decommitting physical memory without releasing virtual memory pages. Hrm. Isn't this already available via OSAllocator or are you referring to the fact that the Posix implementation has a few problems? --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EDITBUGS permission?
(re-sent from correct address) 01 окт. 2013 г., в 11:10, Brendan Long s...@brendanlong.com написал(а): Is this the right mailing list to ask for EDITBUGS permission? This is not a great place, because it's entirely useless noise for most subscribers of this list. http://trac.webkit.org/wiki/CommitterTips says that webkit-committers list is the right place, but I don't think that you can send e-mail to it unless you are already a committer. So, I'm not sure what the canonical best place is. Asking on IRC worked for some people in the past. My email on the WebKit bug tracker is: b.l...@cablelabs.com Done. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson mrobin...@webkit.orgwrote: Here’s a rough task list: (1) Define a canonical GTK platform we’ll use for performance measurement. Perhaps the University of Szeged team has some insight into what platforms they used for comparing allocator performance. I measured the performance and memory for Qt on desktop and on some ARM based embedded devices (e.g. Nokia N9). The blogs are still available on the blog site, but I'm not sure we can consider the numbers as valid after that many years. Please note also, I've working for Adobe for more than a year now, so I don't know whether the University team has any recent public results. The goal for enabling TCmalloc on Qt/Gtk was to match the implementation with the Apple port, which used TCmalloc at time. Please note also, only a subset of QtWebKit platforms uses TCmalloc (linux, mac), the rest of them still uses the default system allocator. (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by global operator new/delete in WebCore+JavaScriptCore. (1a) Either build the API layer as a separate library from WebCore+JavaScriptCore, (1b) or specifically annotate each object at the API library with a per-class operator new / operator delete. I don't think this should be a problem. Currently all allocations of API-level objects happen with the GLib slab allocator (or system malloc/free, given the right environment arguments). (2) Find a fast secure random number API on the canonical GTK platform. I can look into this. (3) Find a fast thread-specific data API on the canonical GTK platform. Threading for GTK+ on non-Mac/non-Windows platforms is essentially pthreads. It probably wouldn't be a lot of work to defer to Windows and Mac implementations on those platforms. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
(4) Find a fast API for aligned virtual memory allocation. (5) Find a fast API for committing / decommitting physical memory without releasing virtual memory pages. Hrm. Isn't this already available via OSAllocator or are you referring to the fact that the Posix implementation has a few problems? OSAllocator is the right model, yes. 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. (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. We need somebody to resolve these issues, otherwise our memory footprint will be unacceptably high, and/or our VM operations will be unacceptably slow. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
Apple's Windows port uses FastMalloc and the last measurements we took show it to be a large performance gain over the default Windows malloc implementation. I believe those measurements were taken 5 Windows versions ago. While this port is only used by iTunes these days, we still would not want to regress its performance. Can the new allocator be made to work with Windows? The set of porting tasks is the same set I outlined for GTK. The Windows port is missing many performance features, including tiled scrolling, LLInt, parallel garbage collection, DFG, and FTL. Given those other major missing pieces, I don’t think this piece is worth the porting time. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
So are you proposing to use the system allocator on Windows? Or would we keep using the existing FastMalloc implementation? 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. -Brent On Oct 1, 2013, at 3:23 PM, Geoffrey Garen gga...@apple.com wrote: Apple's Windows port uses FastMalloc and the last measurements we took show it to be a large performance gain over the default Windows malloc implementation. I believe those measurements were taken 5 Windows versions ago. While this port is only used by iTunes these days, we still would not want to regress its performance. Can the new allocator be made to work with Windows? The set of porting tasks is the same set I outlined for GTK. The Windows port is missing many performance features, including tiled scrolling, LLInt, parallel garbage collection, DFG, and FTL. Given those other major missing pieces, I don’t think this piece is worth the porting time. Geoff ___ 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
On Oct 1, 2013, at 3:35 PM, Brent Fulgham bfulg...@apple.com wrote: So are you proposing to use the system allocator on Windows? Or would we keep using the existing FastMalloc implementation? 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. They would be bad. The default malloc on Windows is very slow. - Maciej -Brent On Oct 1, 2013, at 3:23 PM, Geoffrey Garen gga...@apple.com wrote: Apple's Windows port uses FastMalloc and the last measurements we took show it to be a large performance gain over the default Windows malloc implementation. I believe those measurements were taken 5 Windows versions ago. While this port is only used by iTunes these days, we still would not want to regress its performance. Can the new allocator be made to work with Windows? The set of porting tasks is the same set I outlined for GTK. The Windows port is missing many performance features, including tiled scrolling, LLInt, parallel garbage collection, DFG, and FTL. Given those other major missing pieces, I don’t think this piece is worth the porting time. Geoff ___ 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
On Oct 1, 2013, at 3:05 PM, Geoffrey Garen gga...@apple.com wrote: (3) Find a fast thread-specific data API on the canonical GTK platform. Threading for GTK+ on non-Mac/non-Windows platforms is essentially pthreads. To access thread-specific data using pthreads, you first need to take a lock and call pthread_key_create(). Since the whole point of thread-specific data is to avoid taking a lock, the API is useless. The normal way to do it is to use pthread_once to create the key, which does not in general take a lock. (That or use an out-of-band prior initializer, but that wouldn't work for malloc). You’ll need an alternative to the cross-platform pthread API for accessing thread-specific data. Otherwise, the cost of that API will dominate any other cost, and it won’t be worth our time to try to optimize other things. FastMalloc uses vanilla pthread_getspecific() all the time (including at least on every malloc call) on platforms that don't have a faster form of thread-specific data (such as pthread_getspecific on Mac or __thread on Windows). While it makes a difference, FastMalloc still tends to be faster overall than system malloc implementations. So I suspect it would work ok for the new malloc as well. Probably the easiest way to find out is to test. C++11 also introduces the thread_local keyword which is likely more readily optimizable than function-call-based APIs where supported. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 1, 2013, at 3:11 PM, Geoffrey Garen gga...@apple.com wrote: (4) Find a fast API for aligned virtual memory allocation. (5) Find a fast API for committing / decommitting physical memory without releasing virtual memory pages. Hrm. Isn't this already available via OSAllocator or are you referring to the fact that the Posix implementation has a few problems? OSAllocator is the right model, yes. 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. PageAllocationAligned.cpp does this, but it would be more effective to unmap the unneeded extra at each end (or use mremap on systems that have it). That would be extra VM calls but would not require 2x the space. I'm not sure why it doesn't do that already - perhaps because it is building on top of OSAllocator and no one tried hard enough to optimize it. (The current FastMalloc doesn't try to align its requests for system memory to more than a page boundary so it doesn't have this issue.) (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 don't have the expertise to know what these do or whether it is what we want. But our current malloc uses these, so it would not be a regression for the new malloc to use them even if they are subtly wrong, unless there is something wildly different about its use of system memory. We need somebody to resolve these issues, otherwise our memory footprint will be unacceptably high, and/or our VM operations will be unacceptably slow. Geoff ___ 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
To access thread-specific data using pthreads, you first need to take a lock and call pthread_key_create(). Since the whole point of thread-specific data is to avoid taking a lock, the API is useless. The normal way to do it is to use pthread_once to create the key, which does not in general take a lock. (That or use an out-of-band prior initializer, but that wouldn't work for malloc). Most implementations of pthread_once use a spinlock, or some moral equivalent. Fundamentally, there’s no memory-safe way to implement concurrent one-time execution of arbitrary side effects without a spinlock. That’s why requiring concurrent one-time execution of arbitrary side effects in order to access thread-specific memory is broken API. C++11 also introduces the thread_local keyword which is likely more readily optimizable than function-call-based APIs where supported. thread_local might be a reasonable option, if a platform achieves all the other requirements for fast malloc. It’s still too slow, but at least it isn’t slow by definition, and it doesn’t pollute the rest of the code too badly. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
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. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 1, 2013, at 3:47 PM, Geoffrey Garen gga...@apple.com wrote: To access thread-specific data using pthreads, you first need to take a lock and call pthread_key_create(). Since the whole point of thread-specific data is to avoid taking a lock, the API is useless. The normal way to do it is to use pthread_once to create the key, which does not in general take a lock. (That or use an out-of-band prior initializer, but that wouldn't work for malloc). Most implementations of pthread_once use a spinlock, or some moral equivalent. Fundamentally, there’s no memory-safe way to implement concurrent one-time execution of arbitrary side effects without a spinlock. This implementation from the Linux C library will only ever take a lock in the rare case where initialization has not already been performed, as far as I can tell: http://searchcode.com/codesearch/view/18325089 Assuming my reading is correct, it only ever hits the slow path if initialization has not been performed yet, and multiple threads attempt to do it at once, which happens at most once early in startup. As far as I know, the only significant cost in practice to using pthread_once + pthread_getspecific instead of pthread_getspecific_direct is function call overhead. That is my recollection from when we switched on Mac. That’s why requiring concurrent one-time execution of arbitrary side effects in order to access thread-specific memory is broken API. It's definitely lame, but we have existence proofs that you can still be a lot faster than popular system malloc implementations without solving this problem (namely FastMalloc on Linux platforms today, and FastMalloc as initially deployed on Mac before we adopted pthread_getspecific). Does the new malloc implementation access thread-specific data much more frequently? C++11 also introduces the thread_local keyword which is likely more readily optimizable than function-call-based APIs where supported. thread_local might be a reasonable option, if a platform achieves all the other requirements for fast malloc. It’s still too slow, but at least it isn’t slow by definition, and it doesn’t pollute the rest of the code too badly. Maybe it would be easier to understand what the issue is looking at the code. From this and your other posts, it sounds like there might be an issue of code pollution/complexity and not just prospective performance. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Tue, Oct 1, 2013 at 3:52 PM, Geoffrey Garen gga...@apple.com 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.) I support (1). I think for (2), it would be better if the port maintainers would just try to support the core (the new) allocator if it's possible. It would be better to have only 1 allocator and optionally the system allocator for special cases. Cheers, Zoltan ___ 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)
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.
On Sep 30, 2013, at 10:08 PM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and we’d
like to start work on it. To clarify, the problem is that with CSS generated
content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM node,
we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible
text alternatives for CSS generated content and Tab suggested the property
name. It is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak “New”
instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
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] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
Sounds ok to add it prefixed.
- Maciej
On Oct 1, 2013, at 4:53 PM, James Craig jcr...@apple.com 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.
On Sep 30, 2013, at 10:08 PM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and
we’d like to start work on it. To clarify, the problem is that with CSS
generated content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM
node, we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible
text alternatives for CSS generated content and Tab suggested the property
name. It is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak
“New” instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
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
___
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 4:53 PM, James Craig jcr...@apple.com 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. Regardless, that should be discussed on a separate thread. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: WebKit2 and DrawingAreaImpl
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
