Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl

[Sergio Villar Senin]

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.

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] PSA: WebKit2 and DrawingAreaImpl

[Anders Carlsson]

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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Ryosuke Niwa]

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.

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

Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Maciej Stachowiak]

Sounds ok to add it prefixed.

 - Maciej

On 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.
> 
> On Sep 30, 2013, at 10:08 PM, James Craig  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)

[James Craig]

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  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] WTF::fastMalloc

[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.)

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,

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WTF::fastMalloc

[Maciej Stachowiak]

On Oct 1, 2013, at 3:47 PM, Geoffrey Garen  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

[Geoffrey Garen]

> 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

[Geoffrey Garen]

>> 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

[Maciej Stachowiak]

On Oct 1, 2013, at 3:11 PM, Geoffrey Garen  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

[Maciej Stachowiak]

On Oct 1, 2013, at 3:05 PM, Geoffrey Garen  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

[Maciej Stachowiak]

On Oct 1, 2013, at 3:35 PM, Brent Fulgham  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  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

[Brent Fulgham]

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  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

[Geoffrey Garen]

> 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

[Geoffrey Garen]

>> (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

[Geoffrey Garen]

>> (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.

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.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WTF::fastMalloc

[Zoltan Horvath]

On Tue, Oct 1, 2013 at 11:56 AM, Martin Robinson wrote:

>
> > 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] EDITBUGS permission?

[Alexey Proskuryakov]

(re-sent from correct address)

01 окт. 2013 г., в 11:10, Brendan Long  написал(а):

> 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.  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

[Martin Robinson]

On Tue, Oct 1, 2013 at 11:34 AM, Geoffrey Garen  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] WTF::fastMalloc

[Maciej Stachowiak]

On Sep 30, 2013, at 2:48 PM, Geoffrey Garen  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

[Oliver Hunt]

On Oct 1, 2013, at 11:56 AM, Martin Robinson  wrote:

> On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen  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

[Martin Robinson]

On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen  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.

> (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

[Geoffrey Garen]

> 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

[Geoffrey Garen]

> 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

[webkit-dev] EDITBUGS permission?

[Brendan Long]

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] Changes in QtWebKit development

[Oliver Hunt]

On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen  wrote:

> On Monday 30 September 2013, Oliver Hunt wrote:
>> On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen  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

Re: [webkit-dev] WTF::fastMalloc

[Martin Robinson]

On Mon, Sep 30, 2013 at 7:41 PM, Zoltan Horvath  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] Reference count leak with InBandTextTracks?

[Jer Noble]

On Oct 1, 2013, at 2: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?

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] Reference count leak with InBandTextTracks?

[Brendan Long]

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] Changes in QtWebKit development

[Filip Pizlo]

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  wrote:
> 
>> On Monday 30 September 2013, Oliver Hunt wrote:
>>> On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen  
>>> 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

[webkit-dev] Reference count leak with InBandTextTracks?

[Benjamin Dupont (bedupont)]

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

[Allan Sandfeld Jensen]

On Monday 30 September 2013, Oliver Hunt wrote:
> On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen  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