Re: [webkit-dev] Memory leak tracking in WebKit

2015-11-30 Thread Myles C. Maxfield 
I've got a few questions/statements about this:

1. What makes you think that CSSParser::parseFontFaceSource() is the culprit? 
Which memory instrumentation tools are you using?
2. Font::platformInit() is the function where we start populating all our 
internal font caches. For example, we start creating and populating GlyphPages 
here. It makes sense that it should allocate some memory.
3. Platform fonts are quite heavyweight objects; I would expect these to cost 
more than the work being done in Font::platformInit(). These are allocated in 
FontCache::createFontPlatformData().

If you are able; it might be insightful to take a stack snapshot at every 
memory allocation and aggregate based on the allocation size and the top few 
frames of the stack. With this information, we can try to figure out what the 
memory is being used for, and where it should be released. Then we could try to 
debug why it isn't being released.

> On Nov 30, 2015, at 5:10 PM, Vienneau, Christopher  wrote:
> 
> Hi,
>  
> I’ve still been tracking memory leaks in our application, and I think I have 
> a good test scenario to share. 
>  
> In our application we found that a lot of memory would be held onto when 
> visiting this particular site:
> http://answers.ea.com 
> In a loop we visit this site, and a simple html page that consists of a list 
> of test urls found on the local hard drive.
> Our in built memory tools suggest a leak is coming largely from  
> CSSParser::parseFontFaceSrc(), though admittedly I’ve changed my top suspects 
> from time to time.  I think this item is showing as a large leak due to the 
> inclusion of the font in the css on the answers.ea.com 
>  page, but perhaps there are more smaller items being 
> leaked which is just less obvious (the font is large).
>  
> I’ve reproduce the scenario in the WinCairo test application, based on 
> 188436.  I built in a quick and hacky soak mechanism to conduct the test, 
> perhaps there are better tools I’m not aware of.  I’ve attached the source 
> changes to this mail:
> Source/WebKit/win/WebKitMessageLoop.cpp
> Tools/WinLauncher/Common.cpp
>  
> I can see the memory of the WinLauncher process grow over time, here is an 
> example of the memory usage as seen from the windows task manager over time:
> DurationMemory (reported by windows)
> 0m  155MB
> 13m   178MB
> 23m   199MB
> 36m   219MB  
> 53m   247MB
> 1h4m 259MB
> 1h23m  277MB
> After about an 1h30m, WinLauncher crashes, at the end of the mail is the 
> basic debug data that was available. 
>  
> I’m not sure if the crash is related to the memory leak I’m experiencing, or 
> if it’s an unrelated issue.  Since we’re a few months older from tip I’m 
> wondering if anyone has any recent insights to share on this memory leak 
> scenario? I haven’t identified anything in the change logs, but perhaps there 
> is there something already addressing this?  Does the same issue occur at tip?
>  
> Any feedback is appreciated,
>  
> Thanks
>  
> Chris Vienneau
>  
>  
>  
>  
> + this 0x784be130 
> {m_fontMetrics={m_unitsPerEm=1000 m_ascent=0.0 m_descent=0.0 
> ...} ...} WebCore::Font *
> ascent   0.0   float
> dc   Variable is optimized away and 
> not available. 
> + extents {x_bearing=0.0 
> y_bearing=2.840573810841e-316#DEN width=1.197610077640e-309#DEN ...} 
> cairo_text_extents_t
> metricsMultiplier 
> 0.031250  const double
> faceName   Variable is optimized away 
> and not available. 
> descent52852716.0  
> float
> xHeight Variable is optimized away and not 
> available. 
> + textMetrics{tmHeight=0 tmAscent=0 
> tmDescent=1691286912 ...} tagTEXTMETRICW
> lineGap 63069964.0  float
> scaledFont  0x6477fc00 {...}  
>  _cairo_scaled_font *
> faceLength 0  int
>  
>  
> > WebKit.dll!WebCore::Font::platformInit() Line 82 C++
>WebKit.dll!WebCore::Font::Font(const WebCore::FontPlatformData 
> & platformData, bool isCustomFont, bool isLoading, bool 
> isTextOrientationFallback) Line 80   C++
>WebKit.dll!WebCore::CachedFont::createFont(const 
> WebCore::FontDescription & fontDescription, const WTF::AtomicString & 
> __formal, bool syntheticBold, bool syntheticItalic, bool __formal) Line 126   
>  C+

Re: [webkit-dev] Memory leak tracking in WebKit

2015-11-30 Thread Vienneau, Christopher 
Hi,

I've still been tracking memory leaks in our application, and I think I have a 
good test scenario to share.

In our application we found that a lot of memory would be held onto when 
visiting this particular site:
http://answers.ea.com
In a loop we visit this site, and a simple html page that consists of a list of 
test urls found on the local hard drive.
Our in built memory tools suggest a leak is coming largely from  
CSSParser::parseFontFaceSrc(), though admittedly I've changed my top suspects 
from time to time.  I think this item is showing as a large leak due to the 
inclusion of the font in the css on the answers.ea.com page, but perhaps there 
are more smaller items being leaked which is just less obvious (the font is 
large).

I've reproduce the scenario in the WinCairo test application, based on 188436.  
I built in a quick and hacky soak mechanism to conduct the test, perhaps there 
are better tools I'm not aware of.  I've attached the source changes to this 
mail:
Source/WebKit/win/WebKitMessageLoop.cpp
Tools/WinLauncher/Common.cpp

I can see the memory of the WinLauncher process grow over time, here is an 
example of the memory usage as seen from the windows task manager over time:
DurationMemory (reported by windows)
0m  155MB
13m   178MB
23m   199MB
36m   219MB
53m   247MB
1h4m 259MB
1h23m  277MB
After about an 1h30m, WinLauncher crashes, at the end of the mail is the basic 
debug data that was available.

I'm not sure if the crash is related to the memory leak I'm experiencing, or if 
it's an unrelated issue.  Since we're a few months older from tip I'm wondering 
if anyone has any recent insights to share on this memory leak scenario? I 
haven't identified anything in the change logs, but perhaps there is there 
something already addressing this?  Does the same issue occur at tip?

Any feedback is appreciated,

Thanks

Chris Vienneau




+ this 0x784be130 
{m_fontMetrics={m_unitsPerEm=1000 m_ascent=0.0 m_descent=0.0 
...} ...} WebCore::Font *
ascent   0.0   float
dc   Variable is optimized away and not 
available.
+ extents {x_bearing=0.0 
y_bearing=2.840573810841e-316#DEN width=1.197610077640e-309#DEN ...} 
cairo_text_extents_t
metricsMultiplier 
0.031250  const double
faceName   Variable is optimized away 
and not available.
descent52852716.0  float
xHeight Variable is optimized away and not 
available.
+ textMetrics{tmHeight=0 tmAscent=0 
tmDescent=1691286912 ...} tagTEXTMETRICW
lineGap 63069964.0  float
scaledFont  0x6477fc00 {...}
   _cairo_scaled_font *
faceLength 0  int


> WebKit.dll!WebCore::Font::platformInit() Line 82 C++
   WebKit.dll!WebCore::Font::Font(const WebCore::FontPlatformData & 
platformData, bool isCustomFont, bool isLoading, bool 
isTextOrientationFallback) Line 80   C++
   WebKit.dll!WebCore::CachedFont::createFont(const 
WebCore::FontDescription & fontDescription, const WTF::AtomicString & __formal, 
bool syntheticBold, bool syntheticItalic, bool __formal) Line 126   
 C++
   WebKit.dll!WebCore::CSSFontFaceSource::font(const 
WebCore::FontDescription & fontDescription, bool syntheticBold, bool 
syntheticItalic, WebCore::CSSFontSelector * fontSelector) Line 138 C++
   WebKit.dll!WebCore::CSSFontFace::font(const 
WebCore::FontDescription & fontDescription, bool syntheticBold, bool 
syntheticItalic) Line 127 C++
   WebKit.dll!WebCore::CSSSegmentedFontFace::fontRanges(const 
WebCore::FontDescription & fontDescription) Line 130 C++
   WebKit.dll!WebCore::CSSFontSelector::fontRangesForFamily(const 
WebCore::FontDescription & fontDescription, const WTF::AtomicString & 
familyName) Line 474   C++
   WebKit.dll!WebCore::realizeNextFallback(const 
WebCore::FontDescription & description, unsigned int & index, 
WebCore::FontSelector * fontSelector) Line 90C++
   
WebKit.dll!WebCore::FontCascadeFonts::realizeFallbackRangesAt(const 
WebCore::FontDescription & description, unsigned int index) Line 114
   C++
   WebKit.dll!WebCore::FontCascadeFonts::determinePitch(const 
WebCore::FontDescription & description) Line 64  C++

WebKit.dll!WebCore::BreakingContext::handleText(WTF:

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Geoffrey Garen 
> Seems like we should not have to wait long for the “long term”. It seems that 
> the built-in compiler could start magically transforming “@undefined” instead 
> of magically transforming “undefined” any time we like; likely a simple find 
> and replace job. Or it could do both during a transition period. It could 
> even treat a bare “undefined” as an error if we are worried that we will make 
> that error.

Yup.

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

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Darin Adler 
> On Nov 30, 2015, at 11:57 AM, Geoffrey Garen  wrote:
> 
> For the time being, I like “x === undefined”.
> 
> Long term, I’d like us to switch to “x === @undefined”.
> 
> We use @ to indicate reserved words in built-ins. Currently, “@undefined" 
> does not exist, but the built-in compiler magically transforms “undefined” a 
> safe reserved word.
> 
> The typeof and void 0 code should be fast, but I find it obtuse.

Thanks for all the answers, everyone.

I like Geoff’s proposal.

Seems like we should not have to wait long for the “long term”. It seems that 
the built-in compiler could start magically transforming “@undefined” instead 
of magically transforming “undefined” any time we like; likely a simple find 
and replace job. Or it could do both during a transition period. It could even 
treat a bare “undefined” as an error if we are worried that we will make that 
error.

Then perhaps later we could relieve the built-in compiler of those 
responsibilities if we think that’s important.

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

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Ryosuke Niwa 
On Mon, Nov 30, 2015 at 11:37 AM, Darin Adler  wrote:
> I see the following in some code:
>
> if (xxx === undefined)

FWIW, I always use this style.

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

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Brian Burg 
Web Inspector’s frontend code tends to use “x === undefined”, as we’ve found it 
the easiest to read.

> On Nov 30, 2015, at 11:57 AM, Geoffrey Garen  wrote:
> 
> For the time being, I like “x === undefined”.
> 
> Long term, I’d like us to switch to “x === @undefined”.
> 
> We use @ to indicate reserved words in built-ins. Currently, “@undefined" 
> does not exist, but the built-in compiler magically transforms “undefined” a 
> safe reserved word.
> 
> The typeof and void 0 code should be fast, but I find it obtuse.
> 
> Geoff
> 
>> On Nov 30, 2015, at 11:39 AM, Filip Pizlo  wrote:
>> 
>> I’ve also been guilty of:
>> 
>>  if (xxx === void 0)
>> 
>> This is slightly better than saying “undefined”, since that’s not actually a 
>> reserved word.
>> 
>> I believe that all of these should perform the same.  We should pick one 
>> based on what looks nicest and what has the most clear semantics.
>> 
>> -Filip
>> 
>> 
>> 
>>> On Nov 30, 2015, at 11:37 AM, Darin Adler  wrote:
>>> 
>>> I see the following in some code:
>>> 
>>>  if (xxx === undefined)
>>> 
>>> And I see the following in some other code:
>>> 
>>>  if (typeof xxx == “undefined”)
>>> 
>>>  or
>>> 
>>>  if (typeof xxx === “undefined”)
>>> 
>>> Is one preferred over the other, style-wise? Is one more efficient than the 
>>> other?
>>> 
>>> — Darin
>>> ___
>>> 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

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

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Chris Aljoudi 
FWIW, performance seems to be equivalent:
http://jsperf.com/typeof-vs-undefined-check/39

Chris
https://chrismatic.io/

> On Nov 30, 2015, at 1:01 PM, Geoffrey Garen  wrote:
>
> For the time being, I like “x === undefined”.
>
> Long term, I’d like us to switch to “x === @undefined”.
>
> We use @ to indicate reserved words in built-ins. Currently, “@undefined" 
> does not exist, but the built-in compiler magically transforms “undefined” a 
> safe reserved word.
>
> The typeof and void 0 code should be fast, but I find it obtuse.
>
> Geoff
>
>> On Nov 30, 2015, at 11:39 AM, Filip Pizlo  wrote:
>>
>> I’ve also been guilty of:
>>
>>if (xxx === void 0)
>>
>> This is slightly better than saying “undefined”, since that’s not actually a 
>> reserved word.
>>
>> I believe that all of these should perform the same.  We should pick one 
>> based on what looks nicest and what has the most clear semantics.
>>
>> -Filip
>>
>>
>>
>>> On Nov 30, 2015, at 11:37 AM, Darin Adler  wrote:
>>>
>>> I see the following in some code:
>>>
>>>  if (xxx === undefined)
>>>
>>> And I see the following in some other code:
>>>
>>>  if (typeof xxx == “undefined”)
>>>
>>>  or
>>>
>>>  if (typeof xxx === “undefined”)
>>>
>>> Is one preferred over the other, style-wise? Is one more efficient than the 
>>> other?
>>>
>>> — Darin
>>> ___
>>> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Geoffrey Garen 
For the time being, I like “x === undefined”.

Long term, I’d like us to switch to “x === @undefined”.

We use @ to indicate reserved words in built-ins. Currently, “@undefined" does 
not exist, but the built-in compiler magically transforms “undefined” a safe 
reserved word.

The typeof and void 0 code should be fast, but I find it obtuse.

Geoff

> On Nov 30, 2015, at 11:39 AM, Filip Pizlo  wrote:
> 
> I’ve also been guilty of:
> 
>   if (xxx === void 0)
> 
> This is slightly better than saying “undefined”, since that’s not actually a 
> reserved word.
> 
> I believe that all of these should perform the same.  We should pick one 
> based on what looks nicest and what has the most clear semantics.
> 
> -Filip
> 
> 
> 
>> On Nov 30, 2015, at 11:37 AM, Darin Adler  wrote:
>> 
>> I see the following in some code:
>> 
>>   if (xxx === undefined)
>> 
>> And I see the following in some other code:
>> 
>>   if (typeof xxx == “undefined”)
>> 
>>   or
>> 
>>   if (typeof xxx === “undefined”)
>> 
>> Is one preferred over the other, style-wise? Is one more efficient than the 
>> other?
>> 
>> — Darin
>> ___
>> 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] How to deal with 1-pixel differences in reftests ?

2015-11-30 Thread Myles C. Maxfield 
I believe that any way to specify fuzziness should not treat the following 
cases the same:

- 1 pixel being 100% wrong
- All pixels being 1% wrong

There are certain cases where one of those should cause a failure, but the 
other shouldn't.

--Myles
> On Nov 18, 2015, at 10:44 PM, Alexey Proskuryakov  wrote:
> 
> 
>> 18 нояб. 2015 г., в 11:50, Simon Fraser > > написал(а):
>> 
>> There are some well-understood reasons why a test might not exactly match 
>> its reference. One is that the test uses compositing layers to do clipping, 
>> but the reference just clips with drawing, and these are not expected to 
>> give a pixel-perfect match.
>> 
>> I proposed a way to allow a test to specify a custom tolerance in 
>> https://bugs.webkit.org/show_bug.cgi?id=149828 
>> . If we had this, it would 
>> allow me to fix 142258  and 
>> 146523 .
> 
> Bug 142258 also serves as an example for why we shouldn't do this. Both known 
> reasons for it are actual bugs that needed to be discovered, and need to be 
> fixed.
> 
> What are the causes for flakiness in bug 146523?
> 
> - Alexey
> 
> ___
> 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] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Filip Pizlo 
I’ve also been guilty of:

if (xxx === void 0)

This is slightly better than saying “undefined”, since that’s not actually a 
reserved word.

I believe that all of these should perform the same.  We should pick one based 
on what looks nicest and what has the most clear semantics.

-Filip



> On Nov 30, 2015, at 11:37 AM, Darin Adler  wrote:
> 
> I see the following in some code:
> 
>if (xxx === undefined)
> 
> And I see the following in some other code:
> 
>if (typeof xxx == “undefined”)
> 
>or
> 
>if (typeof xxx === “undefined”)
> 
> Is one preferred over the other, style-wise? Is one more efficient than the 
> other?
> 
> — Darin
> ___
> 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] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Darin Adler 
I see the following in some code:

if (xxx === undefined)

And I see the following in some other code:

if (typeof xxx == “undefined”)

or

if (typeof xxx === “undefined”)

Is one preferred over the other, style-wise? Is one more efficient than the 
other?

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

Re: [webkit-dev] OSX: Linking to custom build resorts to system version...

2015-11-30 Thread S. Litherum 
This sounds to me like SIP is not disabled.

--Myles
> On Nov 29, 2015, at 3:58 AM, Nikolay Tsenkov  wrote:
> 
> I tried this in a testing project, producing an app with a single window with 
> a webView in it, and it doesn’t work. (setting the env variable in the scheme)
> 
> What’s even worse, I actually need to link to the custom WebKit.framework 
> from a dynamic library, not an executable and I guess even if this works for 
> executable, it will not work for a dynamic library project? (It’s a plugin 
> project and an executable I have no control over will load it)
> 
>> On Nov 29, 2015, at 5:39 AM, Dan Bernstein > > wrote:
>> 
>> 
>>> On Nov 11, 2015, at 2:06 AM, Nikolay Tsenkov >> > wrote:
>>> 
>>> Hello,
>>> 
>>> First of all, thanks for the awesome OSS software that WebKit is!
>>> 
>>> I need some help with linking to a fresh build of WebKit.framework on OS X:
>>>  - I am building a modified version of WebKit.framework (my changes are in 
>>> WebCore and WebKit projects) on OS X 10.11, but I am not able to use that 
>>> framework in another project - somehow the project always resorts to the 
>>> default system WebKit.framework.
>>> 
>>> Setup:
>>>  - OS X 10.11.0 (just saw there is 10.11.1 available, but haven’t installed 
>>> it yet)
>>>  - System Integrity Protection (SIP) disabled (I couldn’t build when ON)
>>> 
>>> Changes:
>>>  - (Gist) I am making a version of the WebView (the legacy one, the 
>>> single-process model) which can be used in DAW plugin, exposing API for 
>>> rendering the audio, settings the sampling rate, not rendering to the audio 
>>> hardware directly, etc.
>>>  - (Specific)
>>>  - (WebCore) -Replaced- AudioDestinationMac with AudioDestinationDaw;
>>>  - (WebCore) -Add- DawStateSingleton which exposes the custom 
>>> destination node to the WebView;
>>>  - (WebKit) -Modify- WebView to include a new constructor and couple of 
>>> new methods:
>>> - (instancetype)initWithFrame:(NSRect)frame 
>>> samplingRate:(float)samplingRate frameName:(NSString *)frameName 
>>> groupName:(NSString *)groupName;
>>> - (void)setDawSamplingRate:(float)samplingRate;
>>> - (void)renderAudio:(int) numberOfFrames bufferList:(AudioBufferList*) 
>>> bufferList;
>>> 
>>> In a new project, I am trying to use the new WebView. If I don’t link to 
>>> WebKit.framework, of course, the build fails because it can’t find the 
>>> framework. But if I link to the custom build (the WebView header is the new 
>>> one, I’ve checked) in run time the app breaks with “-[WebView 
>>> initWithFrame:samplingRate:frameName:groupName:]: unrecognized selector 
>>> sent to instance” from which I infer it’s using the system version of the 
>>> WebView.
>>> 
>>> I’ve tried to inspect how the MiniBrowser project correctly is referring to 
>>> the new build, but I don’t see how the linking is happening…
>>> 
>>> Could someone help me out with this?
>>> 
>>> Please, accept my apologies, if there is something simple that I’ve missed.
>> 
>> The most common way to get your executable to pick up your custom built 
>> WebKit instead of the system WebKit is to have your executable run with the 
>> DYLD_FRAMEWORK_PATH environment variable set to the the path where your 
>> built frameworks are. The run-webkit-app script in Tools/Scripts does this. 
>> Or if you’re running your up from within Xcode you can set the environment 
>> variable for the Run action in the scheme editor. There are a few other ways 
>> to get the environment variable set, and some other ways to get your program 
>> to pick up your framework, but I think the above should give you a good 
>> start.
> 
> ___
> 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