Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

2020-07-16 Thread Geoffrey Garen
The original question was, as I understood it, was do we need to support 
non-unified builds as an essential requirement for a given port, and if so, why?

I’d like to finish answering that question, before we wonder off-topic and 
consider whether supporting non-unified builds as an optional way to improve 
our workflow is a good idea.

Thanks,
Geoff

> On Jul 15, 2020, at 4:20 PM, Yusuke Suzuki  wrote:
> 
> And I agree, keeping non-unified build sane is quite useful.
> In addition to the benefit described by Alex, this also allows CMake to 
> generate sane compile_commands.json, so that my completion in Neovim works 
> better in cpp files,
> and I think this compile_commands.json is also used in several clang-related 
> toolings too.
> 
> I think we should have a bot maintaining it.
> 
> -Yusuke
> 
>> On Jul 15, 2020, at 7:33 AM, Alex Christensen > > wrote:
>> 
>> I think it is still quite useful to fix non-unified builds.  Otherwise 
>> adding a file usually involves many unrelated build fixes.
>> 
>>> On Jul 14, 2020, at 5:25 PM, Fujii Hironori >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig >> > wrote:
>>> While I don’t want to take away from what Darin is saying here about 
>>> correct usage of forward declaration and , I’d like to 
>>> understand why we have two different compilation models supported in 
>>> WebKit. Is there a reason both need to be supported? Can we remove one?
>>> 
>>> 
>>> I also want to know that. Does anyone still need non-unified builds?
>>> 
>>> I introduced other unnecessary header inclusion, and Darin asked me to fix 
>>> it.
>>> https://bugs.webkit.org/show_bug.cgi?id=214204#c25
>>>  Reducing header 
>>> inclusion can easily cause build breakages for non-unified builds.
>>> So, I fixed non-unified build breakage in r264332 and r264333 as the 
>>> preparation for that.
>>> Non-unified builds was more broken than I expected. Does anyone still need 
>>> it?
>>> Should we maintain non-unified builds until C++20 modules will nullify 
>>> unified builds?
>>>  
>>> ___
>>> 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] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-24 Thread Geoffrey Garen
OK.

Geooff

> On Jun 24, 2020, at 12:19 PM, Saam Barati  wrote:
> 
> If we're only doing this for JSC, I don't think we need this, as none of us 
> care.
> 
> If we want to do it for all of WK testing, we should include this for folks 
> who care about having O0-style stack traces.
> 
> - Saam
> 
>> On Jun 24, 2020, at 12:17 PM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote:
>> 
>> Is "-fno-inline -fno-optimize-sibling-calls” still on the table?
>> 
>> Thanks,
>> Geoff
>> 
>>> On Jun 24, 2020, at 10:28 AM, Mark Lam >> <mailto:mark@apple.com>> wrote:
>>> 
>>> I forgot to add ...
>>> 
>>>> On Jun 24, 2020, at 10:26 AM, Mark Lam >>> <mailto:mark@apple.com>> wrote:
>>>> 
>>>> Based on all the feedback given so far, it looks like we can move forward 
>>>> with the following plan:
>>>> 1. JSC Debug test bots will build their own local jsc with O3 before 
>>>> running the tests.
>>> 
>>> 1.5 JSC EWS bot will also run with an O3 Debug build.
>>> 
>>> Mark
>>> 
>>>> 2. The rest of the build and test bots will remain unchanged.
>>>> 
>>>> Let's move forward with this and get the Debug JSC test bot functional 
>>>> again.
>>>> 
>>>> Thanks.
>>>> 
>>>> Mark
>>>> 
>>>> 
>>>>> On Jun 19, 2020, at 2:58 PM, Alexey Proskuryakov >>>> <mailto:a...@webkit.org>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> 19 июня 2020 г., в 1:11 PM, Mark Lam >>>>> <mailto:mark@apple.com>> написал(а):
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jun 19, 2020, at 10:24 AM, Geoffrey Garen >>>>>> <mailto:gga...@apple.com>> wrote:
>>>>>>> 
>>>>>>>>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen >>>>>>>> <mailto:gga...@apple.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Can you explain more about what "O3 with no-inlining” is? How does 
>>>>>>>>> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern 
>>>>>>>>> about stack traces, or would something still be different about stack 
>>>>>>>>> traces?
>>>>>>>> There doesn't exist a way to do this now, but it'd be trivial to add a 
>>>>>>>> way. I won't claim it fixes all stack traces differences, but I'd 
>>>>>>>> think compiling using "-fno-inline -fno-optimize-sibling-calls" would 
>>>>>>>> get us pretty far in crashing stack traces being similar enough.
>>>>>>> 
>>>>>>> Sounds good.
>>>>>>> 
>>>>>>> I think we should try to refine the proposal along these lines, to 
>>>>>>> minimize the downsides. I won’t speak for Simon, but for me, being able 
>>>>>>> to ensure a clear backtrace from a bot would be a big improvement.
>>>>>>> 
>>>>>>>>> And again, I think this discussion would get a lot more focused if 
>>>>>>>>> the change could apply only to JSC code, and not also to WTF code.
>>>>>>>> I believe Mark's proposal, initially, is just to make JSC do this. So 
>>>>>>>> I don't see the point of compiling WTF differently. JSC can kick off 
>>>>>>>> its own build, and run Debug+O3 tests faster than it can run Debug+O0 
>>>>>>>> tests. Given people working on JSC want this, and people working on 
>>>>>>>> JSC defend these tests, and that these test results are more stable 
>>>>>>>> (see below), we should make this change for JSC.
>>>>>>>> 
>>>>>>>> I was trying to convince folks defending non-JSC testing, that they 
>>>>>>>> too, should want this. I'm not going to pull teeth here. If folks want 
>>>>>>>> their tests to take ~10x longer to run, they're entitled to make that 
>>>>>>>> tradeoff.
>>>>>>> 
>>>>>>> Got it.
>>>>>> 
>>>>>> I'm of the same mind as Saam.  We want this change for the JSC bots, and 
>>>>>> fr

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-24 Thread Geoffrey Garen
Is "-fno-inline -fno-optimize-sibling-calls” still on the table?

Thanks,
Geoff

> On Jun 24, 2020, at 10:28 AM, Mark Lam  wrote:
> 
> I forgot to add ...
> 
>> On Jun 24, 2020, at 10:26 AM, Mark Lam > <mailto:mark@apple.com>> wrote:
>> 
>> Based on all the feedback given so far, it looks like we can move forward 
>> with the following plan:
>> 1. JSC Debug test bots will build their own local jsc with O3 before running 
>> the tests.
> 
> 1.5 JSC EWS bot will also run with an O3 Debug build.
> 
> Mark
> 
>> 2. The rest of the build and test bots will remain unchanged.
>> 
>> Let's move forward with this and get the Debug JSC test bot functional again.
>> 
>> Thanks.
>> 
>> Mark
>> 
>> 
>>> On Jun 19, 2020, at 2:58 PM, Alexey Proskuryakov >> <mailto:a...@webkit.org>> wrote:
>>> 
>>> 
>>> 
>>>> 19 июня 2020 г., в 1:11 PM, Mark Lam >>> <mailto:mark@apple.com>> написал(а):
>>>> 
>>>> 
>>>> 
>>>>> On Jun 19, 2020, at 10:24 AM, Geoffrey Garen >>>> <mailto:gga...@apple.com>> wrote:
>>>>> 
>>>>>>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen >>>>>> <mailto:gga...@apple.com>> wrote:
>>>>>>> 
>>>>>>> Can you explain more about what "O3 with no-inlining” is? How does 
>>>>>>> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern 
>>>>>>> about stack traces, or would something still be different about stack 
>>>>>>> traces?
>>>>>> There doesn't exist a way to do this now, but it'd be trivial to add a 
>>>>>> way. I won't claim it fixes all stack traces differences, but I'd think 
>>>>>> compiling using "-fno-inline -fno-optimize-sibling-calls" would get us 
>>>>>> pretty far in crashing stack traces being similar enough.
>>>>> 
>>>>> Sounds good.
>>>>> 
>>>>> I think we should try to refine the proposal along these lines, to 
>>>>> minimize the downsides. I won’t speak for Simon, but for me, being able 
>>>>> to ensure a clear backtrace from a bot would be a big improvement.
>>>>> 
>>>>>>> And again, I think this discussion would get a lot more focused if the 
>>>>>>> change could apply only to JSC code, and not also to WTF code.
>>>>>> I believe Mark's proposal, initially, is just to make JSC do this. So I 
>>>>>> don't see the point of compiling WTF differently. JSC can kick off its 
>>>>>> own build, and run Debug+O3 tests faster than it can run Debug+O0 tests. 
>>>>>> Given people working on JSC want this, and people working on JSC defend 
>>>>>> these tests, and that these test results are more stable (see below), we 
>>>>>> should make this change for JSC.
>>>>>> 
>>>>>> I was trying to convince folks defending non-JSC testing, that they too, 
>>>>>> should want this. I'm not going to pull teeth here. If folks want their 
>>>>>> tests to take ~10x longer to run, they're entitled to make that tradeoff.
>>>>> 
>>>>> Got it.
>>>> 
>>>> I'm of the same mind as Saam.  We want this change for the JSC bots, and 
>>>> from the time measurements I’ve collected, we can afford to do a clean 
>>>> build for the JSC Debug test runs using O3, and still come out way ahead.
>>> 
>>> This seems like a reasonable plan. You didn't mention what hardware you 
>>> measured with, but it seems certain to be beneficial on any current 
>>> hardware.
>>> 
>>> I need to mention that we saw unexplained and very large impact on JSC test 
>>> speed from enabling/disabling TCSM. That may be a good thing to look into 
>>> while optimizing JSC test speed.
>>> 
>>> - Alexey
>>> 
>>> 
>>>> As for non-JSC test runs, I have not actually measured what the time 
>>>> savings are.  Given there is resistance to going with O3 there, we don’t 
>>>> have to share the build artifacts for running the tests.  JSC test runs 
>>>> should be able to just build JSC for each O3 Debug JSC test run and it is 
>>>> still a win over the current status quo i.e. test runs never complete.
>>>> 
>>>> Regarding Geoff’s earlie

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-19 Thread Geoffrey Garen
>> On Jun 19, 2020, at 8:04 AM, Geoffrey Garen > <mailto:gga...@apple.com>> wrote:
>> 
>> Can you explain more about what "O3 with no-inlining” is? How does 
>> --force-opt=O3 avoid inlining? Would this fully resolve Simon concern about 
>> stack traces, or would something still be different about stack traces?
> There doesn't exist a way to do this now, but it'd be trivial to add a way. I 
> won't claim it fixes all stack traces differences, but I'd think compiling 
> using "-fno-inline -fno-optimize-sibling-calls" would get us pretty far in 
> crashing stack traces being similar enough.

Sounds good.

I think we should try to refine the proposal along these lines, to minimize the 
downsides. I won’t speak for Simon, but for me, being able to ensure a clear 
backtrace from a bot would be a big improvement.

>> And again, I think this discussion would get a lot more focused if the 
>> change could apply only to JSC code, and not also to WTF code.
> I believe Mark's proposal, initially, is just to make JSC do this. So I don't 
> see the point of compiling WTF differently. JSC can kick off its own build, 
> and run Debug+O3 tests faster than it can run Debug+O0 tests. Given people 
> working on JSC want this, and people working on JSC defend these tests, and 
> that these test results are more stable (see below), we should make this 
> change for JSC.
> 
> I was trying to convince folks defending non-JSC testing, that they too, 
> should want this. I'm not going to pull teeth here. If folks want their tests 
> to take ~10x longer to run, they're entitled to make that tradeoff.

Got it.

>> And again, on the run more tests front, it would be helpful to know whether 
>> this change was enough to get the stress tests running or not.
> My experience running the tests locally supports this fully. I don't get 
> timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd 
> get timeouts all the time, and the total test run would take ~4-8 hours. We 
> can wait for official confirmation from Mark.

Alexey, do the JSC stress tests run now on bots? If not, how fast would they 
need to run in order to be eligible to run on bots?

Thanks,
Geoff

> 
> - Saam
> 
>> 
>> Thanks,
>> Geoff
>> 
>>> On Jun 18, 2020, at 9:30 PM, Saam Barati >> <mailto:sbar...@apple.com>> wrote:
>>> 
>>> Why are we insisting on doing something on the bots that takes ~10x longer 
>>> to run than necessary? I’d rather have that time spent running more tests.
>>> 
>>> Overall, how we’re doing things now feels like a bad allocation of bot 
>>> resources. The differences I see between O3 with no-inlining vs O0 is:
>>> - Some race conditions will behave differently. Race conditions are already 
>>> non predictable. I don’t think we’re losing anything here.
>>> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in 
>>> O0, and vice versa. In general, we probably care more about O3 compiler 
>>> bugs than O0, since we don’t ship O0, but ship a lot of O3.
>>> 
>>> (And if we’re going to insist on “I want it to run what I build at my 
>>> desk”: I run debug with O3 at my desk, and I can run debug tests in a 
>>> reasonable amount of time now.)
>>> 
>>> In evaluating what’s the better setup, I think it’s helpful to think about 
>>> this from the other side. Let’s imagine we had Debug+O3 as our current 
>>> setup. And someone proposed to move it to O0 and make our tests take ~10x 
>>> longer. I think that’d be a non-starter.
>>> 
>>> - Saam
>>> 
>>>> On Jun 17, 2020, at 9:48 PM, Simon Fraser >>> <mailto:simon.fra...@apple.com>> wrote:
>>>> 
>>>> I also object to losing good stack traces for crashes on Debug bots.
>>>> 
>>>> Also, I don't think Debug bots should build something different from what 
>>>> I build at my desk.
>>>> 
>>>> Simon
>>>> 
>>>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >>>> <mailto:mark@apple.com>> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>>> <http://build.webkit.org/> Debug build and test bots to building with the 
>>>>> following set first:
>>>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>>>> 
>>>>> This means the Debug builds will be built with optimization level forced 
>>>>> to O3.
>>>>> 
>

Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-19 Thread Geoffrey Garen
Can you explain more about what "O3 with no-inlining” is? How does 
--force-opt=O3 avoid inlining? Would this fully resolve Simon concern about 
stack traces, or would something still be different about stack traces?

And again, I think this discussion would get a lot more focused if the change 
could apply only to JSC code, and not also to WTF code.

And again, on the run more tests front, it would be helpful to know whether 
this change was enough to get the stress tests running or not.

Thanks,
Geoff

> On Jun 18, 2020, at 9:30 PM, Saam Barati  wrote:
> 
> Why are we insisting on doing something on the bots that takes ~10x longer to 
> run than necessary? I’d rather have that time spent running more tests.
> 
> Overall, how we’re doing things now feels like a bad allocation of bot 
> resources. The differences I see between O3 with no-inlining vs O0 is:
> - Some race conditions will behave differently. Race conditions are already 
> non predictable. I don’t think we’re losing anything here.
> - O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in 
> O0, and vice versa. In general, we probably care more about O3 compiler bugs 
> than O0, since we don’t ship O0, but ship a lot of O3.
> 
> (And if we’re going to insist on “I want it to run what I build at my desk”: 
> I run debug with O3 at my desk, and I can run debug tests in a reasonable 
> amount of time now.)
> 
> In evaluating what’s the better setup, I think it’s helpful to think about 
> this from the other side. Let’s imagine we had Debug+O3 as our current setup. 
> And someone proposed to move it to O0 and make our tests take ~10x longer. I 
> think that’d be a non-starter.
> 
> - Saam
> 
>> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
>> 
>> I also object to losing good stack traces for crashes on Debug bots.
>> 
>> Also, I don't think Debug bots should build something different from what I 
>> build at my desk.
>> 
>> Simon
>> 
>>> On Jun 17, 2020, at 1:36 PM, Mark Lam >> > wrote:
>>> 
>>> Hi folks,
>>> 
>>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>>  Debug build and test bots to building with the 
>>> following set first:
>>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>>> 
>>> This means the Debug builds will be built with optimization level forced to 
>>> O3.
>>> 
>>> Why are we doing this?
>>> 1. So that the JSC EWS will start catching ASSERT failures.
>>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>>> all.  Hopefully, this change will fix this issue.
>>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>>> 
>>> The downside: crash stack traces will be like Release build stack traces.  
>>> But I don’t think we should let this deter us.  It’s not like there’s no 
>>> stack information.  And just as we do with debugging Release build test 
>>> failures, we can always do a Debug build locally to do our debugging.
>>> 
>>> We would like to apply this change to all Debug build and test bots, not 
>>> just the JSC ones.  Does anyone strongly object to this change?
>>> 
>>> Thanks.
>>> 
>>> Cheers,
>>> Mark
>>> 
>>> ___
>>> 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] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-18 Thread Geoffrey Garen
Better JSC debugging in exchange for worse debugging in non-JSC code that calls 
through to WTF is not a great tradeoff.

Is there a way to localize this change to only JSC?

Do we know for sure that this change would get stress tests running, or are we 
just guessing? Can we find out? It’s easier to weight a tradeoff between known 
quantities than it is to weigh a tradeoff between hoped-for quantities.

Thanks,
Geoff

> On Jun 18, 2020, at 9:55 AM, Ryan Haddad  wrote:
> 
>> 
>> On Jun 18, 2020, at 9:44 AM, Alex Christensen > > wrote:
>> 
>> It sounds to me like Mark’s suggestion does not lose anything.  It’s just 
>> for JSC “Debug”
> 
> The post-commit JSC bots use the same build products as the other debug 
> testers, so with our current setup it would have to apply to other queues as 
> well.
> 
> Ryan
> 
>> which currently is not running because it’s too slow.  If he called it 
>> “ReleaseWithAssert” it would make it more clear what is going on and we 
>> would all appreciate the additional information those bots provide.
>> 
>>> On Jun 17, 2020, at 9:48 PM, Simon Fraser >> > wrote:
>>> 
>>> I also object to losing good stack traces for crashes on Debug bots.
>>> 
>>> Also, I don't think Debug bots should build something different from what I 
>>> build at my desk.
>>> 
>>> Simon
>>> 
 On Jun 17, 2020, at 1:36 PM, Mark Lam >>> > wrote:
 
 Hi folks,
 
 We're planning to switch the JSC EWS bot and build.webkit.org 
  Debug build and test bots to building with the 
 following set first:
 ./Tools/Scripts/set-webkit-configuration --force-opt=O3
 
 This means the Debug builds will be built with optimization level forced 
 to O3.
 
 Why are we doing this?
 1. So that the JSC EWS will start catching ASSERT failures.
 2. JSC stress test Debug bots have been timing out and not running tests 
 at all.  Hopefully, this change will fix this issue.
 3. Tests will run to completion faster and we’ll catch regressions sooner.
 
 The downside: crash stack traces will be like Release build stack traces.  
 But I don’t think we should let this deter us.  It’s not like there’s no 
 stack information.  And just as we do with debugging Release build test 
 failures, we can always do a Debug build locally to do our debugging.
 
 We would like to apply this change to all Debug build and test bots, not 
 just the JSC ones.  Does anyone strongly object to this change?
 
 Thanks.
 
 Cheers,
 Mark
 
 ___
 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 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] 2019 WebKit Contributors Meeting - Hurry! Registration is Closing!

2019-10-25 Thread Geoffrey Garen
The Login page looks like this:



If you click the  link, it takes you to 
https://webkit.org/auth/wregister <https://webkit.org/auth/wregister>. 

I’m not sure what “not used for registration this year means”; but what I mean 
is that this link is present on the page, and clicking it loads an error page.

Thanks,
Geoff

> On Oct 24, 2019, at 11:11 PM, Ling Ho  wrote:
> 
> Hi Geoff,
> 
> Please go to https://webkit.org/auth/wlogout/ 
> <https://webkit.org/auth/wlogout/> and make sure you are not logged in. Then 
> go to https://www.webkit.org/meeting <https://www.webkit.org/meeting> and 
> make sure the pages says "2019 WebKit Contributors Meeting". After that, try 
> logging in and register again. The "https://webkit.org/auth/wregister 
> <https://webkit.org/auth/wregister>" is not used for registration this year.
> 
> ...
> ling
> 
> On 10/24/19 9:12 PM, Geoffrey Garen wrote:
>> https://webkit.org/auth/wregister <https://webkit.org/auth/wregister>
>> 
>> Internal Server Error
>> 
>> The server encountered an internal error or misconfiguration and was unable 
>> to complete your request.
>> 
>> Please contact the server administrator at ad...@webkit.org 
>> <mailto:ad...@webkit.org> to inform them of the time this error occurred, 
>> and the actions you performed just before this error.
>> 
>> More information about this error may be available in the server error log.
>> 
>> 
>>> On Oct 23, 2019, at 4:06 PM, Jonathan Davis >> <mailto:j...@apple.com>> wrote:
>>> 
>>> Hello WebKit Contributors,
>>> 
>>> This is a short reminder that your chance to register to attend the WebKit 
>>> Contributors Meeting is closing after Friday, October 25th!
>>> 
>>> Please be sure you’ve registered for the meeting at 
>>> https://webkit.org/meeting/ <https://webkit.org/meeting/>
>>> 
>>> The schedule of topics is filling in, but there are still a couple of 
>>> larger time slots available. If you have a topic you’d like to present for 
>>> discussion, please send me an email to secure a spot on the schedule.
>>> 
>>> Note that the longer prepared talks are anywhere between 30-40 minutes 
>>> leaving time for questions and discussions before the next session. If you 
>>> have a short topic to present, email me about giving a 5-10 minute 
>>> lightning talk.
>>> 
>>> See you next Friday!
>>> 
>>> Jon Davis
>>> 
>>>> On Sep 18, 2019, at 1:47 PM, Jonathan Davis >>> <mailto:j...@apple.com>> wrote:
>>>> 
>>>> Hello WebKit Contributors,
>>>> 
>>>> You are invited to attend the annual WebKit Contributors Meeting to be 
>>>> held at the Hilton Santa Clara hotel on Friday, November 1st, 2019 from 8 
>>>> AM to 6 PM Pacific.
>>>> 
>>>> Breakfast and sign-in will begin at 8 AM. Presentations will run between 9 
>>>> AM to 6 PM. Lunch will be provided with all day coffee, tea and a 
>>>> mid-afternoon snack break. A reception is planned at the venue after the 
>>>> meeting with dinner and drinks from 6 PM to 9 PM.
>>>> 
>>>> To attend you must be an active WebKit contributor. The meeting will be 
>>>> free of charge, and registration is open. Register at 
>>>> https://webkit.org/meeting/ <https://webkit.org/meeting/> 
>>>> 
>>>> The event format will include a mix of prepared talks around 40 minutes 
>>>> long with 10-15 minutes of questions, and spontaneous lightning talks 
>>>> about 5-10 minutes long. If you have a topic idea that you want to 
>>>> present, please email me directly.
>>>> 
>>>> We look forward to seeing you there!
>>>> 
>>>> Thank you,
>>>> Jon Davis
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <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] 2019 WebKit Contributors Meeting - Hurry! Registration is Closing!

2019-10-24 Thread Geoffrey Garen
https://webkit.org/auth/wregister 

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to 
complete your request.

Please contact the server administrator at ad...@webkit.org to inform them of 
the time this error occurred, and the actions you performed just before this 
error.

More information about this error may be available in the server error log.


> On Oct 23, 2019, at 4:06 PM, Jonathan Davis  wrote:
> 
> Hello WebKit Contributors,
> 
> This is a short reminder that your chance to register to attend the WebKit 
> Contributors Meeting is closing after Friday, October 25th!
> 
> Please be sure you’ve registered for the meeting at 
> https://webkit.org/meeting/ 
> 
> The schedule of topics is filling in, but there are still a couple of larger 
> time slots available. If you have a topic you’d like to present for 
> discussion, please send me an email to secure a spot on the schedule.
> 
> Note that the longer prepared talks are anywhere between 30-40 minutes 
> leaving time for questions and discussions before the next session. If you 
> have a short topic to present, email me about giving a 5-10 minute lightning 
> talk.
> 
> See you next Friday!
> 
> Jon Davis
> 
>> On Sep 18, 2019, at 1:47 PM, Jonathan Davis > > wrote:
>> 
>> Hello WebKit Contributors,
>> 
>> You are invited to attend the annual WebKit Contributors Meeting to be held 
>> at the Hilton Santa Clara hotel on Friday, November 1st, 2019 from 8 AM to 6 
>> PM Pacific.
>> 
>> Breakfast and sign-in will begin at 8 AM. Presentations will run between 9 
>> AM to 6 PM. Lunch will be provided with all day coffee, tea and a 
>> mid-afternoon snack break. A reception is planned at the venue after the 
>> meeting with dinner and drinks from 6 PM to 9 PM.
>> 
>> To attend you must be an active WebKit contributor. The meeting will be free 
>> of charge, and registration is open. Register at https://webkit.org/meeting/ 
>>  
>> 
>> The event format will include a mix of prepared talks around 40 minutes long 
>> with 10-15 minutes of questions, and spontaneous lightning talks about 5-10 
>> minutes long. If you have a topic idea that you want to present, please 
>> email me directly.
>> 
>> We look forward to seeing you there!
>> 
>> Thank you,
>> Jon Davis
> 
> ___
> 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] Drop x86 (32bit) JIT backend

2019-09-13 Thread Geoffrey Garen
No objection.

Geoff

> On Sep 13, 2019, at 1:39 PM, Yusuke Suzuki  wrote:
> 
> Hello all,
> 
> Now, Xcode no longer has ability to build 32bit binary.
> Fedora starts dropping x86 32bit kernel shipping.
> Our x86/x86_64 JIT requires SSE2, so such CPUs can use JIT if they want by 
> switching x86 to x86_64.
> And these CPUs are modern enough to run CLoop at high speed.
> 
> x86 32bit JIT backend is very complicated and is being a major maintenance 
> burden.
> This is due to very few # of registers. Which scatters a lot of isX86 / 
> CPU(X86) in Baseline, DFG, and Yarr.
> I’m now planning to optimize some part of Yarr, but x86 YarrJIT is being a 
> major barrier of such cleanups / optimizations.
> 
> So, I would like to propose dropping X86 32bit JIT support.
> 
> -Yusuke
> ___
> 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] JavaScriptCore to C++ JSLock questions

2019-02-15 Thread Geoffrey Garen
Hi Werner.

There’s no API around this. If you’re sure you don’t need thread safety, you 
can probably manually change JavaScriptCore not to do that locking.

Geoff

> On Feb 15, 2019, at 6:54 AM, Werner Sharp  wrote:
> 
> Hi everyone,
>  
> I’m working on a project that uses JavaScriptCore in interpreted mode along 
> with a lot of C++ classes referenced from JS based upon the JSClassRef 
> concept.  From doing some profiles, the transition from JSC to C++ (or 
> vice-versa) is quite costly because of JSLockHolder, JSLock::dropAllLocks, 
> etc.  I assume there is no way around this in a single threaded single 
> instance of the VM?  Or no way from C++ to wrap a set of JSObjectGet* type of 
> calls in a block somehow allowing only one lock to happen. For example, I 
> need to query 6 properties of a pure JS object from C++.  That takes 6 round 
> trips into JSC so 6 locks unless I do something like return a string 
> representation of the 6 properties and parse them in my C++ code.
>  
> On a related note, one thing I’ve found slow is my own implementation of my 
> C++ class’s hasInstance because of the locking.  I tried to leave the 
> JSClassRef hasInstance NULL assuming that the internal instanceOf would work 
> properly.  But that doesn’t appear to work because the JSCallbackObject 
> always sets the ImplementsHasInstance flag but not the 
> ImplementsDefaultHasInstance flag. I would think that 
> “JSCallbackObject::customHasInstance” could be enhanced to call 
> defaultHasInstance if JSObjectHasInstanceCallback hasInstance always returns 
> false?
>  
> Or if there is some way that defautHasInstance can be called for a 
> JSCallbackObject I’d appreciate to hear about it.
>  
> Thanks for your time.
>  
> Werner Sharp
>  
>  
> ___
> 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] Code Style: Opinion on returning void

2019-02-07 Thread Geoffrey Garen
FWIW, I’ve always felt conflicted about this case.

I very much prefer early return to if/else chains.

However, “return f()” when f returns void is a bit mind bending.

So, I can’t use my preferred style in functions that return void. Boo. 

Geoff

> On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
> 
> Hi all,
> 
> Something bothers me about code like:
> 
> void f();
> void g()
> {
> if (...)
> return f();
> return f();
> }
> 
> I prefer:
> 
> void g()
> {
> if (...) {
> f();
> return
> }
> f();
> }
> 
> Does it bother you? For the former? For the latter? Update our style guide?
> 
> Opinions, please.
> 
> Dan
> ___
> 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] the name "AtomicString"

2018-12-20 Thread Geoffrey Garen
>>> So hard to pronounce though! Why not UniqueString? It’s not quite as 
>>> explicit but close enough. 
>> 
>> Wouldn’t it be confusing to use UniqueString type for a string that is 
>> *common* in order to save memory?
> 
> I would interpret it as UniqueString(foo) means “give me the unique copy of 
> string foo”. You use a unique copy so you can use the same string in many 
> places without wasting memory, or excess time on string compares. It’s used 
> in many places, but there is only one. (Maybe we should call it 
> HighlanderString? OK, not serious.)

By definition, any string that has been uniqued is unique.

So, maybe we like “unique” or maybe we don’t. But if we like “unique”, it’s 
strictly better than “uniqued”.

>> Personally, I like the AtomString proposal as it is close to the naming we 
>> are used to and addresses the issue raised (atomic has a different meaning 
>> with threading).
>> Also, I had never heard of interned strings before.

AtomicString has two features:

(1) You do comparison by pointer / object identity;

(2) You never allocate two objects for the same sequence of characters.

JavaScript symbols offer (1) but avoid (2):

let a = Symbol(“The string of the past!”);
let b = Symbol(“The string of the past!”);
a == b; // false
a === b; // false

Today we call (1) “UniquedStringImpl” and (1) + (2) “AtomicStringImpl”.

If we rename (1) + (2) to “UniqueString” or “UniquedString”, we need a new name 
for (1) alone.

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


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Geoffrey Garen
   
>>  
>>   
>> // b null? 0 
>>  
>>  
>> 
>> 
>> As you can see, the internals of callee dontUseParameter (which could be in 
>> a different translation unit) affects the state of the local variable b in 
>> this function.  This is one of the reasons why the state of a moved-from 
>> variable is intentionally undefined, and we can’t fix that by using our own 
>> std::optional replacement.  If we care about the state of a moved-from 
>> object, that is what std::exchange is for.  I think we should do something 
>> to track and prevent the use of moved-from values instead of introducing our 
>> own std::optional replacement.
>> 
>>> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa >> <mailto:rn...@webkit.org>> wrote:
>>> 
>>> Yeah, it seems like making std::optional more in line with our own 
>>> convention provides more merits than downsides here. People are using 
>>> WTFMove as if it's some sort of a swap operation in our codebase, and as 
>>> Maciej pointed out, having rules where people have to think carefully as to 
>>> when & when not to use WTFMove seems more troublesome than the proposed 
>>> fix, which would mean this work for optional.
>>> 
>>> - R. Niwa
>>> 
>>> On Mon, Dec 17, 2018 at 2:24 PM Geoffrey Garen >> <mailto:gga...@apple.com>> wrote:
>>> I don’t understand the claim about “undefined behavior” here. As Maciej 
>>> pointed out, these are our libraries. We are free to define their behaviors.
>>> 
>>> In general, “undefined behavior” is an unwanted feature of programming 
>>> languages and libraries, which we accept begrudgingly simply because there 
>>> are practical limits to what we can define. This acceptance is not a 
>>> mandate to carry forward undefined-ness as a badge of honor. In any case 
>>> where it would be practical to define a behavior, that defined behavior 
>>> would be preferable to undefined behavior.
>>> 
>>> I agree that the behavior of move constructors in the standard library is 
>>> undefined. The proposal here, as I understand it, is to (a) define the 
>>> behaviors move constructors in WebKit and (b) avoid std::optional and use 
>>> an optional class with well-defined behavior instead.
>>> 
>>> Because I do not ❤️ security updates, I do ❤️ defined behavior, and so I ❤️ 
>>> this proposal.
>>> 
>>> Geoff
>>> 
>>>> On Dec 17, 2018, at 12:50 PM, Alex Christensen >>> <mailto:achristen...@apple.com>> wrote:
>>>> 
>>>> This one and the many others like it are fragile, relying on undefined 
>>>> behavior, and should be replaced by std::exchange.  Such a change was made 
>>>> in https://trac.webkit.org/changeset/198755/webkit 
>>>> <https://trac.webkit.org/changeset/198755/webkit> and we probably need 
>>>> many more like that, but we are getting away with relying on undefined 
>>>> behavior which works for us in most places.
>>>> 
>>>>> On Dec 17, 2018, at 11:24 AM, Chris Dumez >>>> <mailto:cdu...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 17, 2018, at 11:10 AM, Chris Dumez >>>>> <mailto:cdu...@apple.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Dec 17, 2018, at 10:27 AM, Alex Christensen >>>>>> <mailto:achristen...@apple.com>> wrote:
>>>>>>> 
>>>>>>>>>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez >>>>>>>>>> <mailto:cdu...@apple.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> As far as I know, our convention in WebKit so far for our types has 
>>>>>>>>>>> been that types getting moved-out are left in a valid “empty” state.
>>>>>>> This is not necessarily true.  When we move out of an object to pass 
>>>>>>> into a function parameter, for example, the state of the moved-from 
>>>>>>> object depends on the behavior of the callee.  If the callee function 
>>>>>

Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Geoffrey Garen
I don’t understand the claim about “undefined behavior” here. As Maciej pointed 
out, these are our libraries. We are free to define their behaviors.

In general, “undefined behavior” is an unwanted feature of programming 
languages and libraries, which we accept begrudgingly simply because there are 
practical limits to what we can define. This acceptance is not a mandate to 
carry forward undefined-ness as a badge of honor. In any case where it would be 
practical to define a behavior, that defined behavior would be preferable to 
undefined behavior.

I agree that the behavior of move constructors in the standard library is 
undefined. The proposal here, as I understand it, is to (a) define the 
behaviors move constructors in WebKit and (b) avoid std::optional and use an 
optional class with well-defined behavior instead.

Because I do not ❤️ security updates, I do ❤️ defined behavior, and so I ❤️ 
this proposal.

Geoff

> On Dec 17, 2018, at 12:50 PM, Alex Christensen  wrote:
> 
> This one and the many others like it are fragile, relying on undefined 
> behavior, and should be replaced by std::exchange.  Such a change was made in 
> https://trac.webkit.org/changeset/198755/webkit 
>  and we probably need many 
> more like that, but we are getting away with relying on undefined behavior 
> which works for us in most places.
> 
>> On Dec 17, 2018, at 11:24 AM, Chris Dumez > > wrote:
>> 
>> 
>> 
>>> On Dec 17, 2018, at 11:10 AM, Chris Dumez >> > wrote:
>>> 
>>> 
>>> 
 On Dec 17, 2018, at 10:27 AM, Alex Christensen >>> > wrote:
 
 On Dec 14, 2018, at 1:37 PM, Chris Dumez >>> > wrote:
>>> 
 
 As far as I know, our convention in WebKit so far for our types has 
 been that types getting moved-out are left in a valid “empty” state.
 This is not necessarily true.  When we move out of an object to pass into 
 a function parameter, for example, the state of the moved-from object 
 depends on the behavior of the callee.  If the callee function uses the 
 object, we often have behavior that leaves the object in an “empty” state 
 of some kind, but we are definitely relying on fragile undefined behavior 
 when we do so because changing the callee to not use the parameter changes 
 the state of the caller.  We should never assume that WTFMove or std::move 
 leaves the object in an empty state.  That is always a bug that needs to 
 be replaced by std::exchange.
>>> 
>>> Feel like we’re taking about different things. I am talking about move 
>>> constructors (and assignment operators), which have a well defined behavior 
>>> in WebKit. And it seems you are talking about WTFMove(), which despite the 
>>> name does not “move” anything, it is merely a cast.
>>> In the case you’re talking about the caller does NOT call the move 
>>> constructor, it merely does a cast so I do not think your comment 
>>> invalidates my statement. Note that in my patch, I was nearly WTFMove()ing 
>>> the data member and assigning it to a local variable right away, calling 
>>> the move constructor.
>> 
>> Also note that may of us already rely on our move constructors’ behavior, 
>> just search for WTFMove(m_responseCompletionHandler) in:
>> https://trac.webkit.org/changeset/236463/webkit 
>> 
> ___
> 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] Watch out for std::optional's move constructor

2018-12-15 Thread Geoffrey Garen
> This expression WTFMove(*m_pendingWebsitePolicies) doesn't move 
> std::optional, but moves the content of the 
> std::optional, WebsitePoliciesData. I think your proposal doesn't work for 
> this code.

The original code, which asserted, did this:

if (auto pendingWebsitePolicies = WTFMove(m_pendingWebsitePolicies))

WebsitePoliciesData::applyToDocumentLoader(WTFMove(*pendingWebsitePolicies), 
documentLoader);

The relevant expression was "WTFMove(m_pendingWebsitePolicies)”, which did move 
std::optional. The expectation in the code was that, after 
WTFMove(m_pendingWebsitePolicies), m_pendingWebsitePolicies would be empty.

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


Re: [webkit-dev] Huge improvement in Safari results on wpt.fyi

2018-10-11 Thread Geoffrey Garen
Honest question: What’s gross about using @font-face?

It would be lots of test edits. That’s a bummer.

But maybe it’s clearer for the tests to specify the font they want to use. It 
makes the test self-describing, eliminating the requirement that the user take 
a step outside the test to get the right result.

Thanks,
Geoff

> On Oct 11, 2018, at 6:01 PM, Dean Jackson  wrote:
> 
> It turns out that many (most?) of the CSS failures are because we no longer 
> expose user-installed fonts, e.g. Ahem.
> 
> Options:
> 
> - update lots of tests to load Ahem via @font-face (yuck)
> - allow Ahem to be used if installed (weird to special case one font, but 
> probably ok)
> 
> Dean
> 
>> On 12 Oct 2018, at 03:26, Philip Jägenstedt  wrote:
>> 
>> Alright, I've written a one-off script [1] to find the Safari-only
>> failures, and here's the output:
>> https://gist.github.com/foolip/4d410ce79416bcdce71feb212159a02e
>> 
>> Barring bugs, each of linked tests or one of its subtests should be
>> failing in Safari Technology Preview and passing in stable versions of
>> Chrome, Edge and Firefox.
>> 
>> Numerically, most of the failures are in css (622), encoding (135) and
>> html (60). With css, it's mostly css/CSS2.
>> 
>> I hope looking through this may be of use to you!
>> 
>> [1] https://github.com/foolip/ad-hoc-wpt-results-analysis
>> 
>> On Mon, Oct 8, 2018 at 11:50 PM Philip Jägenstedt  
>> wrote:
>>> 
>>> That filtering capability unfortunately does not yet exist on wpt.fyi
>>> but it's a high priority and actively being worked on:
>>> https://github.com/web-platform-tests/wpt.fyi/issues/201
>>> 
>>> FWIW, I suspect that these purposes, comparing to the stable versions
>>> of all *other* browsers might be the most useful:
>>> https://wpt.fyi/results/?product=chrome%5Bstable%5D=edge%5Bstable%5D=firefox%5Bstable%5D=safari%5Bexperimental%5D
>>> 
>>> Again, no way to filter on wpt.fyi, but I'll see if I can download the
>>> full results and write a quick script.
>>> 
>>> On Thu, Oct 4, 2018 at 11:49 PM Ryosuke Niwa  wrote:
 
 Thanks for the intriguing data, Philip.
 
 Is there a way to get a list of tests where all other browsers pass but 
 Safari / WebKit fail?
 
 That would allow us to quickly identify the set of tests we can fix to 
 improve the interoperability across browsers right away.
 
 - R. Niwa
 
 On Tue, Oct 2, 2018 at 3:45 AM Philip Jägenstedt  
 wrote:
> 
> Hi WebKittens,
> 
> Fresh off the bots, I'm excited to report more robust Safari results,
> and that Safari WPT pass rates are clearly improving! Thanks to the
> hard work of Mike Pennisi [1] we now have the first Safari 12 results:
> https://wpt.fyi/results/?sha=ee2e69bfb1=safari-12.0
> 
> This uses the same setup as for Safari Technology Preview, which has
> been running for a while [2] and are the results you see on the
> "experimental" view:
> https://wpt.fyi/results/?label=experimental
> 
> This appears much more robust than the Safari 11 data we've collected
> from Sauce Labs, and we can see a massive improvement between Safari
> 11 and 12:
> https://wpt.fyi/results/?sha=ee2e69bfb1=safari-11.1=safari-12.0
> 
> This lumps together infrastructure improvements as well as Safari
> 11->12 improvements, but improvements in service-workers/ [3] stands
> out, as well as in webdriver/, referrer-policy/, css/css-align/, and
> others. (The effect of moving away from Sauce is mainly less
> timeouts.)
> 
> Also very interesting is to compare Safari 12 stable to TP:
> https://wpt.fyi/results/?sha=ee2e69bfb1=safari-12.0=safari-12.1
> 
> One can tell that work is going in canvas-related things,
> web-animations/, css/css-logical/ and more! \o/
> 
> I hope you'll all find these results valuable, and please report bugs
> or feature requests here:
> https://github.com/web-platform-tests/wpt.fyi/issues
> 
> P.S. We're also trying to use use these diff views to spot
> regressions. It's a bit hard to use, [4] but a fix in in progress [5]
> and I might check back here when that works. I'll append to the end of
> this email a non-exhaustive list of possible regressions already
> possible to spot.
> 
> [1] https://github.com/web-platform-tests/results-collection/issues/604
> [2] https://wpt.fyi/test-runs?labels=safari,experimental
> [3] 
> https://wpt.fyi/results/service-workers?sha=ee2e69bfb1=safari-11.1=safari-12.0=true
> [4] https://github.com/web-platform-tests/wpt.fyi/issues/411
> [5] https://github.com/web-platform-tests/wpt.fyi/pull/609
> 
> P.P.S. Possible regressions in Safari TP:
> https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/shapes1?sha=ee2e69bfb1=safari-12.0=safari-12.1
> 

Re: [webkit-dev] Unified sources have broken our #include hygiene

2018-09-02 Thread Geoffrey Garen
FWIW, this problem is caused by unified sources *and* precompiled headers.

> Unified sources allow you to get away without #including all the files you 
> need in a .cpp file, because some earlier file in the group has probably 
> already included them for you.
> 
> This means that when you add a new file to the build, and the unified sources 
> get shuffled around, you end up with a long list of build breakages, some 
> platform-specific, that you can only fix by repeating EWS trials. Here's an 
> example: https://bugs.webkit.org/show_bug.cgi?id=189223. That patch added on 
> new file in Source/WebCore/rendering, which required unrelated #include 
> changes in at least:
> 
> rendering/RenderBlockFlow.cpp:
> rendering/RenderFrame.cpp:
> rendering/RenderImage.cpp:
> 
> How can we solve this? Should we have an EWS that builds non-unified? Can we 
> somehow have the style checker do #include enforcement?

I think the solution to eagerly fix unified vs non-unified missing #includes 
would be strictly more costly than the problem — since the problem is that you 
sometimes have to fix unified vs non-unified missing #includes.

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


Re: [webkit-dev] bmalloc design question about relation with std malloc

2018-04-30 Thread Geoffrey Garen
If we have just a few allocations, we should use the mmap based allocator. This 
preserves the invariant that bmalloc can be used as a general-purpose malloc 
implementation.

If we have lots of small allocations, we should probably reconsider the design.

I’m not familiar with the new uses of std::vector inside bmalloc. That’s not 
something I would recommend.

Geoff

> On Apr 30, 2018, at 3:35 AM, Yusuke SUZUKI  wrote:
> 
> Hi, WebKittens,
> 
> IIRC, bmalloc uses mmap based page allocator for internal memory use. For 
> example, bmalloc::Vector uses it instead of calling malloc.
> But recent changes start using std::vector, which means it uses std malloc 
> under the hood.
> 
> So my question is, if we want some internal memory allocation in bmalloc, 
> shoud we use std::malloc? Or should we use mmap based allocator?
> 
> Best regards,
> Yusuke Suzuki
> -- 
> Regards,
> Yusuke Suzuki
> ___
> 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] Proposal: Do not support Windows fibers

2017-12-05 Thread Geoffrey Garen
If our Windows clients are cool with it, I think we should remove support for 
fibers.

I don’t think our current implementation works super well with fibers. It is 
best not to include half-working code in the tree.

Geoff

> On Dec 5, 2017, at 11:19 AM, Michael Saboff  wrote:
> 
> Here is the reply from iTunes for the WebKit-Dev list
> 
> - Michael
> 
> ——
> 
> From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber 
> API support.
> 
> iTunes still uses some cooperative threading, but implements its own 
> mechanism on top of regular preemptive Windows threads. And we believe we've 
> fixed all occurrences of calling WebKit/JSC from our non-main cooperative 
> threads.
> 
> - John
> 
>> On Dec 5, 2017, at 10:26 AM, Michael Saboff > > wrote:
>> 
>> [Bringing John Lehner from the iTunes team into the discussion]
>> 
>> Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
>> into WebKit/JSC only has one fiber, other parts of the app use multiple 
>> fibers on one thread but don’t have JS objects active in those threads / 
>> fibers.
>> 
>> John, have things changed for iTunes on Windows such that we can eliminate 
>> support for fibers?
>> 
>> - Michael
>> 
>>> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa >> > wrote:
>>> 
>>> Yeah, I don't think there is much need to support fibers. With features 
>>> like web workers, supporting fibers doesn't make much sense.
>>> 
>>> - R. Niwa
>>> 
>>> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI >> > wrote:
>>> Hi, Webkittens,
>>> 
>>> I would like to make sure OR declare that WebKit does not support Windows 
>>> fibers.
>>> While fiber related functions are used in WTF, I believe that it is because 
>>> fiber local storage (FLS) can have destructors. And it is not intended to 
>>> support fibers explicitly.
>>> 
>>> Actually, I believe the current WebKit does not work well with Windows 
>>> fibers right now.
>>> For example, our JSC GC is conservative for stack and registers. It means 
>>> that GC needs to scan stack and registers to gather conservative roots. But 
>>> if your fiber is not executed at that time, JSC GC will miss to scan the 
>>> stack and registers of those inactive fibers. As a result, managed objects 
>>> will be collected if it is only referenced from the roots in the inactive 
>>> fibers.
>>> 
>>> And I think we can potentially improve performance of our TLS by using 
>>> thread_local implementation in VC++ instead of using FLS. FLS is slow and 
>>> it causes some problems[1]. I'm not sure the performance characteristics 
>>> and implementation details of thread_local in VC++, but it's worth checking.
>>> 
>>> So, I think we should not support Windows fibers. I would like to hear 
>>> opinions about it.
>>> 
>>> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 
>>> 
>>> 
>>> Best regards,
>>> Yusuke Suzuki
>>> 
>>> ___
>>> 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

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-31 Thread Geoffrey Garen
> - have code completion and symbol navigation work very nicely in Xcode

Unified builds will likely make this work better.

Fun fact about Xcode: The way it does symbol indexing for symbols in a header 
is that it compiles the header with a random .cpp and indexes the result. The 
more stuff in your .cpp file, the more likely that the indexed result will be 
correct! :P

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


Re: [webkit-dev] Breakpoints in #included .cpp files [Was: Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)]

2017-08-30 Thread Geoffrey Garen
"target.inline-breakpoint-strategy always” is also the workaround suggested in 
the bugs Simon cited.

Note that this setting is also necessary to fix a bunch of bugs with 
breakpoints in headers.

Geoff

> On Aug 29, 2017, at 11:03 PM, Rik Cabanier <caban...@gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 29, 2017 at 8:48 PM, Simon Fraser <simon.fra...@apple.com 
> <mailto:simon.fra...@apple.com>> wrote:
> > On Aug 28, 2017, at 9:46 PM, Geoffrey Garen <gga...@apple.com 
> > <mailto:gga...@apple.com>> wrote:
> >
> >> The line numbers and filenames will be total nonsense if we just 
> >> concatenate multiple source files together. But that's very easy to fix if 
> >> the script that concatenates the sources also adds a #line statement 
> >> between "files" to change the filename and reset the line number to 1. See 
> >> https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html 
> >> <https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html> (I suspect it will 
> >> work just fine for Clang as well).
> >
> > Our plan is to use #include. That has worked in the past.
> 
> This should be tested before proceeding with the unified build plan. This has 
> certainly not always worked in the past (for Apple folks, see 
> rdar://problem/16751849 and rdar://problem/16829492, which is still open).
> 
> Non-working breakpoints would be a show-stopper for many.
> 
> Mozilla has been concatenating source files for a number of years. I don't 
> remember that they had to treat static specially but you did have to 
> configure XCode so you could set the breakpoints.
> 
> See https://dxr.mozilla.org/mozilla-central/source/.lldbinit#17 
> <https://dxr.mozilla.org/mozilla-central/source/.lldbinit#17>
> 
>  

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Geoffrey Garen
Interesting.

The majority cases here are 7 or fewer files. I don’t see much difference 
between these cases and our existing benchmark for one file, where Keith 
described the build time delta as "barely noticeable".

For the minority cases that are 23 - 75 files, these challenge Keith’s 
description that "most of the build time in incremental builds is scanning 
dependencies” — assuming that you get unlucky enough for none of the files to 
bundle together.

If possible, it would be helpful to know if these files were in the same 
folders or not.

Alternatively, we can approximate the answer by benchmarking svn up for 
individual revisions.

Geoff

> On Aug 29, 2017, at 2:21 PM, Dan Bernstein <m...@apple.com> wrote:
> 
> 
> 
>> On Aug 29, 2017, at 1:39 PM, Geoffrey Garen <gga...@apple.com 
>> <mailto:gga...@apple.com>> wrote:
>> 
>>> I see. The right question to ask would have been how much change occurs in 
>>> their working copy between consecutive incremental builds.
>> 
>> If you want to help make our benchmark righter, please do share any data you 
>> have about the average content of an incremental build that is distinct from 
>> a daily svn up.
> 
> Here is the data from three WebKit contributors surveyed today. For each 
> contributor, each line corresponds to a single consecutive incremental build 
> they’ve performed today, and the number shown is the number of files that 
> were compiled in that build:
> 
> A
> B
> C
> 41
> 4
> 1
> 2
> 1
> 1
> 
> 1
> 1
> 
> 4
> 7
> 
> 4
> 58
> 
> 5
> 27
> 
> 3
> 23
> 
> 4
> 61
> 
> 5
> 3
> 
> 7
> 75
> 
> 1
> 2
> 
> 6
> 1
> 
> 4
> 2
> 
> 4
> 1
> 
> 4
> 47
> 
> 5
> 
> 
> 3
> 
> 
> I hope this helps. It certainly gives me an idea of what a righter benchmark 
> would be.

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Geoffrey Garen
> I see. The right question to ask would have been how much change occurs in 
> their working copy between consecutive incremental builds.

If you want to help make our benchmark righter, please do share any data you 
have about the average content of an incremental build that is distinct from a 
daily svn up.

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Geoffrey Garen
>> We have some preliminary data that says incremental builds will be OK, but 
>> not a full benchmark.
>> 
>> Here’s a full benchmark I propose to test incremental builds:
>> 
>>  Start 7 days ago in SVN history. Do a clean build.
>> 
>>  SVN update forward by 24 hours. Do an incremental build. Time this 
>> build.
>> 
>>  Repeat 7 times. Average the results.
> 
> How did you arrive at a day’s worth of changes being representative of a 
> WebKit contributor’s incremental build?

I asked some people how often they svn up and they said every day.

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Geoffrey Garen
> This isn’t the scenario I find myself in most often.  A much more common 
> scenario is working on a change; touch one or two files, and then compile and 
> test/debug.  Rinse and repeat.

We’ve already tested this case. The worst case slowdown, if you touch a small 
file that's in the same bundle as the biggest .cpp file in the project, is 6s 
=> 7s (20%).

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Geoffrey Garen
> I worry about adopting unity build because while it makes clean builds 
> faster, it also slows down incremental builds. As a developer, I rarely do 
> clean builds, I mostly do incremental builds so this would likely make my 
> experience worse?

We have some preliminary data that says incremental builds will be OK, but not 
a full benchmark.

Here’s a full benchmark I propose to test incremental builds:

Start 7 days ago in SVN history. Do a clean build.

SVN update forward by 24 hours. Do an incremental build. Time this 
build.

Repeat 7 times. Average the results.

I think we should run this benchmark per project as we adopt unity builds, 
starting with WTF.

In the beginning, when we adopt unity builds for WTF and then JavaScriptCore, 
the benchmark can build just these projects and stop. Once we get to WebCore 
and WebKit, the benchmark will take longer. Oh well.

If we get the bundling right, this benchmark should show obvious speedups. If 
it shows no speedup or a slowdown, we’ve done something wrong and we need to 
reconsider.

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Geoffrey Garen
> I wonder whether the unified sources builds would still allow us to
> keep using compiler caches like ccache.

Our plan is to use ccache.

> Second question/caveat is, wouldn't the bundle build penalize too much
> incremental builds? If your data is correct we would get a <20% build
> time increment for a single change in a cpp file which is I think the
> most common scenario for a WebKit developer.

The penalty for a single file compile is roughly 6s => 7s. The speedup for a 
full project build is roughly 40m => 10m. You would need to perform single file 
compiles 1,800 times per full project build before the tradeoff became “too 
much”.

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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-28 Thread Geoffrey Garen
> The line numbers and filenames will be total nonsense if we just concatenate 
> multiple source files together. But that's very easy to fix if the script 
> that concatenates the sources also adds a #line statement between "files" to 
> change the filename and reset the line number to 1. See 
> https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html (I suspect it will work 
> just fine for Clang as well).

Our plan is to use #include. That has worked in the past.

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


Re: [webkit-dev] Question regarding per-file BSD license text

2017-08-22 Thread Geoffrey Garen
> My understanding is that if a non-Apple contributor adds a new file, their 
> affiliation should only be reflected in the copyright line and NOT in the BSD 
> license text itself (which reads "APPLE INC."), because the latter is a 
> "per-file copy of a project-wide license". Could someone confirm whether or 
> not this is correct?

Correct.

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


Re: [webkit-dev] Removing support for CSS regions

2017-08-15 Thread Geoffrey Garen
>> Given my concern is the compatibility, not the maintenance cost, what
>> is the evidence that nobody is relying on this feature?

It’s difficult to prove a negative. Impossible, in fact.

Can anyone present evidence of a major client of CSS regions?

If not, I think that lack of evidence — in combination with the lack of support 
for CSS regions in other browsers — is the best we’ll be able to do to know 
that the feature can be removed.

Disabling at runtime might give us a little more information, but we don’t have 
a huge beta population and app developers don’t test against trunk WebKit, so 
it’s not that much information. Also, adding runtime enable/disable checks for 
a fundamental layout feature moves in the opposite direction of the goal, which 
is to simplify the code.

Maybe a compromise path is to disable parsing of CSS regions at compile time, 
but leave all the code in place, and then remove all the code after a Safari 
Technology Preview ships without incident. Would you feel better about that 
than just removing CSS regions right away?

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


Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

2017-06-19 Thread Geoffrey Garen
 Another minor comment: it seems like this new API returns raw data. It 
 seems like the native way to use this would result in running untrusted 
 data from the network through image decoders outside the Web Process 
 sandbox. Do we have a way to avoid that?
>>> 
>>> This came up while implementing it for Safari, too. In practice we didn't 
>>> decode icons out-of-process before so this model was not a regression. I 
>>> see value in offering this, but it's also something conscientious clients 
>>> can do on their own with the raw data.
>> 
>> Didn’t we need to create the Safari ImageDecoder service to work around the 
>> problem of decoding untrusted icon images?
> 
> That’s not going to be available to other participants in the WebKit Open 
> Source projects.

Sorry — I don't mean to suggest that other projects should adopt Safari's 
ImageDecoder service. I just want to clarify that Maciej’s concern is more than 
theoretical.

I would add that I don’t like the idea that it’s the client’s job to be 
“conscientious” in order to achieve safe rendering of web content. The point of 
Modern WebKit as a framework is that all clients should get safe rendering by 
default.

Therefore, I think it’s a flaw that the current API vends only raw encoded data.

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


Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

2017-06-19 Thread Geoffrey Garen
>> Another minor comment: it seems like this new API returns raw data. It seems 
>> like the native way to use this would result in running untrusted data from 
>> the network through image decoders outside the Web Process sandbox. Do we 
>> have a way to avoid that?
> 
> This came up while implementing it for Safari, too. In practice we didn't 
> decode icons out-of-process before so this model was not a regression. I see 
> value in offering this, but it's also something conscientious clients can do 
> on their own with the raw data.

Didn’t we need to create the Safari ImageDecoder service to work around the 
problem of decoding untrusted icon images?

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


Re: [webkit-dev] Port WebKit to GNUstep

2017-05-11 Thread Geoffrey Garen
No.

The bar is much higher for introducing a new port to WebKit.

Geoff

> On May 11, 2017, at 7:54 PM, Daniel Ferreira (theiostream)  
> wrote:
> 
> Hi there,
> 
> My name is Daniel Ferreira and as a Google Summer of Code project I
> decided to tackle the ten-year-long[1] effort of porting WebKit to
> GNUstep one more time (and hopefully get somewhere this time).
> 
> Since 2009, GNUstep has gained a lot of maturity in its graphics stack
> and on its implementation of CoreFoundation, so now having a WebKit
> port in it seems like a more plausible goal – as well as a fun
> challenge. This is very important to GS since it still has no web
> browser running on top of it.
> 
> Also since 2009, it seems like WebKit has gained mature ports on GTK
> and Qt, which has made the demand for a GNUstep port quite smaller for
> the project. However, it does seem interesting to offer a
> cross-platform port that adds portability to a lot of currently
> Mac-specific code – a goal a GNUstep port would fulfill.
> 
> In an ideal world, GNUstep would be mature enough for us to build the
> Mac port on a Linux machine pointing to GNUstep libraries and all
> would be well. Sadly, this is not the case and a GNUstep port on
> WebKit would require some adjustments on WebKit (although GNUstep
> certainly would receive many patches as well implementing stuff WebKit
> would use).
> 
> That being said, I decided to try compiling WTF as a first approach to
> this undertaking, and I introduced a "PlatformGNUstep.cmake" file that
> is mostly a copy of PlatformMac.cmake. It ends up defining
> WTF_PLATFORM_MAC and WTF_PLATFORM_GNUSTEP as code macros, and whenever
> there is some Mac-specific code that GNUstep can't tackle, we try a
> cross-platform alternative. Otherwise, the behavior is just like that
> of the Mac port.
> 
> Through some adjustments to WebKit code (e.g. GNUstep does not support
> XPC, QOS, Mach kernel memory operations, so in these cases we either
> do nothing or use Linux-specific code as an implementation) and
> GNUstep adjustments (regarding some missing CoreFoundation functions),
> I managed to get WTF compiled and linked. I'm now moving on to
> JavaScriptCore to be able to test everything (and very likely spend
> quite some time figuring out the most diverse issues that will show
> up).
> 
> That being said, I will send a patch as soon as I get JSC in a
> semi-decent state. However I wondered if this introduce new platform +
> do the same thing as Mac port with some exceptions approach seems
> reasonable to the project now that I have realized it is actually
> feasible.
> 
> Thanks,
> -- Daniel.
> 
> [1]: https://lists.webkit.org/pipermail/webkit-dev/2009-October/010333.html
> ___
> 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] Performance Difference between Webkit and Wekit2 API's

2017-05-10 Thread Geoffrey Garen
Though I don’t have specific numbers to share, WebKit2’s design generally 
provides much better performance under these conditions:

(1) Faster: Long-running JavaScript programs on iOS;

(2) Faster and smoother: Scrolling;

(3) Faster and smoother: More than one webpage open at once;

(4) Less memory use: opening and closing many webpages over time.

Geoff

> On May 10, 2017, at 6:19 AM, Rodney Dowdall  
> wrote:
> 
> Hello
> 
> We currently have a port of WebKit that uses the WebKit API.  It works well, 
> but the performance isn't quite at the level of some other WebKit ports.  
> 
> I was wondering if there would be an expected performance gain by using the 
> Webkit2 API.  My line of thinking is that the streamlining that takes place 
> under the WebKit API could be killing our performance. 
> 
> Are there any performance numbers that show if there is a difference between 
> the two API's? 
> 
> Thanks,
> Rodney
> -- 
>   
> Rodney Dowdall
> Senior Software Developer 
> t. +1 (613) 595 1999 x513 <>  
> e. rdowd...@cranksoftware.com  
>  
> w. www.cranksoftware.com   
> 
> 
> ___
> 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] Another WPT bite

2017-05-09 Thread Geoffrey Garen
> Another concern is the ease of running tests for developers: drag 
> tests into a browser instead of running a server.

Yeah, it’s a pretty big concern if you can’t just drop a simple test case into 
a browser.

> We can partially accommodate this by rewriting 
> testharness.js/testharnessreport.js urls.
> A significant and growing amount of wpt tests will not behave as expected 
> (other resources loaded, origins, need for specific headers, need for https…)

This might be a reason to prefer WPT tests when you know you’re testing 
something whose behavior depends on http. But in all other cases, the ability 
for a test to be a self-contained file that can run in any browser, upload to a 
bug tracker, and so on, is super valuable.

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


Re: [webkit-dev] Another WPT bite

2017-05-09 Thread Geoffrey Garen
> What we're suggesting is to give preferential treatments to
> testharness.js over js-test.js / js-test-pre.js when you were already
> planning to write a test with the latter two scripts.

OK, I think this makes sense.

But I still think the very best kind of test is a flat file with 10-20 lines of 
code in it. Particularly for debugging JavaScript issues, large wrapper 
frameworks get in the way.

> - Tests would be more easily upstreamable to web-platform-tests, which are 
> run by all major browser engines. This would help a lot in terms of 
> interoperability. As previously discussed, Gecko and Blink already do 
> automated export of tests to web-platform-tests. I believe we should do in 
> the same direction and contribute more tests back.

I wonder why these other projects do automated export instead of incorporating 
testharness.js directly.

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


Re: [webkit-dev] Another WPT bite

2017-05-08 Thread Geoffrey Garen
> Is it time to make testharness.js the recommended way of writing LayoutTests?

What are the costs and benefits of testharness.js?

We usually try to make regression tests reductions of some larger problem to 
aid debugging and to make testing fast. But testharness.js is 95kB. That's kind 
of the opposite of a reduction.

Geoff

> 
> To continue moving forward, some of us are proposing to serve all tests in 
> LayoutTests/wpt through the WPT server [1].
> This would serve some purposes like increasing the use of WPT goodies: 
> file-specific headers, templated tests (*.any.js), IDLParser, server-side 
> scripts...
> It could also ease test migration from WebKit to W3C WPT.
> 
> Some rules can guide whether adding tests to LayoutTests/wpt or 
> LayoutTests/imported/w3c/web-platform-tests:
> - WebKit specific tests (crash tests, tests using internals...) in 
> LayoutTests/wpt
> - Spec conformance/interoperability tests in 
> LayoutTests/imported/w3c/web-platform-tests
> 
>y
> 
> [1]: bug 171479 
> 
> 
> ___
> 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] !!Tests for equality comparison

2017-04-28 Thread Geoffrey Garen
> but == should be used for testing things where 0 is just another number, like 
> indexes:
> 
> if (index == 0)
>…

The index case is especially annoying because we use -1 to indicate notFound, 
so !index means “the first valid index” rather than “no index”. It’s pretty odd 
to think of false as the first valid array index. I wouldn’t want someone to 
write “x = array[false]”.

Also:

If (point.x == 0)
…

If (gps.latitude == 0)
   …

etc.

These are the cases where ! really grinds my gears.

Perhaps we could relax the rule to say:

Tests for true / false and null / non-null should use if (x) / if (!x) instead 
of equality comparisons:

If (ptr)
ptr->func()

Tests for numeric values where 0 indicates falsiness or emptiness should also 
use if (x) / if (!x).

If (!collection.size())
return;

Other comparisons to numeric values should use equality comparisons:

if (index == 0)
...

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


Re: [webkit-dev] !!Tests for equality comparison

2017-04-27 Thread Geoffrey Garen
>> On Apr 27, 2017, at 16:30, Geoffrey Garen <gga...@apple.com 
>> <mailto:gga...@apple.com>> wrote:
>> 
>> I’ve never really liked this style rule, and I’ve always felt like it snuck 
>> into the style document without much discussion.
> 
> It date from 2009: https://bugs.webkit.org/show_bug.cgi?id=27333 
> <https://bugs.webkit.org/show_bug.cgi?id=27333>
This is just a rote copy of the the pre-existing rule, which was recorded by a 
website check-in. I don’t have enough svn foo to make it past our website 
reorganization and find that check-in.

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


Re: [webkit-dev] !!Tests for equality comparison

2017-04-27 Thread Geoffrey Garen
I’ve never really liked this style rule, and I’ve always felt like it snuck 
into the style document without much discussion.

Even so, I usually tolerate it.

Geoff

> On Apr 27, 2017, at 4:06 PM, JF Bastien  wrote:
> 
> Hello C++ fans!
> 
> The C++ style check currently say:
> Tests for true/false, null/non-null, and zero/non-zero should all be done 
> without equality comparisons
> 
> I totally agree for booleans and pointers… but not for integers. I know it’s 
> pretty much the same thing, but I it takes me slightly longer to process code 
> like this:
> 
> int numTestsForEqualityComparison = 0:
> // Count ‘em!
> // …
> if (!numTestsForEqualityComparison)
>   printf(“Good job!”);
> 
> I read it as “if not number of tests for equality comparison”. That's weird. 
> It takes me every slightly longer to think about, and I’ve gotten it wrong a 
> bunch of times already. I’m not trying to check for “notness", I’m trying to 
> say “if there were zero tests for equality comparison”, a.k.a.:
> 
> if (numTestsForEqualityComparison == 0)
>   printf(“Good job!”);
> 
> So how about the C++ style let me just say that? I’m not suggesting we advise 
> using that style for integers everywhere, I’m just saying it should be 
> acceptable to check zero/non-zero using equality comparison.
> 
> 
> !!Thanks (i.e. many thanks),
> 
> JF
> 
> p.s.: With you I am, fans of Yoda comparison, but for another day this will 
> be.
> ___
> 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] Proposal: upstream the WPE port

2017-04-21 Thread Geoffrey Garen
I think the biggest consideration here is the problems we’ve noticed in the C 
API that have produced poor designs that we don’t intend to support going 
forward.

Does the WPE port’s API need to be backwards-compatible in a source or binary 
way?

Is it practical for the WPE port’s API to mirror the ObjC API?

Thanks,
Geoff

> On Apr 21, 2017, at 2:24 PM, Alex Christensen  wrote:
> 
> This is exciting news, Zan!  I’m happy to see innovative new uses of WebKit.
> 
> What kind of groups hope to use this new port?  What kind of groups hope to 
> maintain this new port?  Will it be beneficial to the WebKit community to 
> have their cooperative work?  I see having more groups motivated to organize 
> things in a supportable way as positive.
> 
> I don’t think we should just use the C API as it is.  We want to eventually 
> remove it completely.  If we do upstream WPE, I propose doing something like 
> one of the following:
> 1. We could make a new C API that more closely mirrors the Cocoa API, to 
> which we only add things we have committed to support.  This should be done 
> in collaboration with the existing API owners.
> 2. We could mark parts of the existing C API as part of the API we have 
> committed to maintaining.  There is a lot of messy stuff in the existing C 
> API we eventually want to remove even before we remove the whole thing (old 
> client versions, testing-only functions, private functions that access things 
> we want to eventually organize differently, etc.).  For example, a lot of the 
> things in WKContextPrivate.h should be moved from a multi-process-global 
> approach to a WKWebView/WKPage-based organization.  The basic concepts are 
> here to stay, though.
> 3. Have third parties who use the API just deal with whatever changes we 
> throw at them.  This could be viable if there were only a few small groups 
> using the API, but it would hinder innovative use of the API.  We might want 
> to reserve the right to make API breaking changes anyway, though.
> 
>> On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote:
>> 
>> Hi,
>> 
>> the WebKit team at Igalia would like to propose upstreaming the WPE port
>> of WebKit, taking on the duty to maintain it alongside the GTK+ port.
>> 
>> The WPE port started in 2014 as the 'WebKit for Wayland' project inside
>> Igalia [1].  The port was derived from the GTK+ port, but avoided
>> dependency on any GUI toolkit.  It relied on the Wayland display
>> protocol for on-screen presentation.  That dependency was later dropped
>> in favor of using generic interfaces to adapt to different
>> platform-specific presentation systems.  This allows any vendor to
>> simply provide the necessary backend implementations that are tailored
>> to their platform.
>> 
>> The port is intended to be the Web platform engine of choice for
>> embedded Linux systems.  Since late 2014 Igalia has been sponsored by
>> Metrological to further develop the WPE port, targeting primarily
>> various set-top box platforms.  Miguel Gomez blogged about this effort
>> back in December [2].  The port can also address other embedded use
>> cases, for instance in-vehicle infotainment or digital signage.
>> 
>> The GTK+ and WPE ports mostly have the same dependencies except for the
>> GTK+ toolkit library.  That enables the two ports to already share a lot
>> of code.  The biggest difference between the two is that the WPE port
>> exposes the WebKit2 C API, while the GTK+ port exposes a GObject-based
>> API.  Apart from that, the maintainers' plan is to further align the two
>> ports as much as possible, ideally simply stacking the GTK+ port on top
>> of WPE, with only a few additional tweaks for GTK+ integration.  This
>> would lessen the maintenance burden for both ports and the project as a
>> whole.
>> 
>> The WebKit team at Igalia thinks this port is on stable footing and has
>> solid prospects for the future.  That's why we'd like to join the
>> upstream community and continue our work there.
>> 
>> The patch with the port changes is in bug #171110 [3].  We have existing
>> x86_64 buildbot configurations [4] that we would have to port over to
>> the webkit.org build master.  We're planning further builder and tester
>> configurations for ARM architectures in the future.  Layout test
>> baselines would be landed separately.  (Those too would be subject to
>> alignment with the GTK+ port.)
>> 
>> We're happy to address any questions or considerations.
>> 
>> Regards,
>> Zan
>> 
>> [1]
>> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027087.html
>> [2]
>> https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for-embedded/
>> [3] https://bugs.webkit.org/show_bug.cgi?id=171110
>> [4] https://build-webkit.igalia.com/waterfall?category=WPE
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

2017-03-28 Thread Geoffrey Garen
ure 129 frames instead of 31722 in 
>>> this case? Do they have a hardcoded limit?
>> 
>> Actually, my previous frame counts are a bit off.  I was using 
>> e.stack.split(/\r\n|\r|\n/).length as the frame count.  Below, I just copy 
>> the console.log dump into an editor and take the line count from there as 
>> the frame count instead.  The result of that string.split appears to be a 
>> bit off from the actual frames printed by console.log. 
>> 
>> I also modified my recursing test function to console.log the re-entry count 
>> on entry and this is what I saw:
>> 
>> 1. Chrome
>> test reported reentry count = 10150
>> split(…).length = 11 (because Chromes starts e.stack with a line 
>> "RangeError: Maximum call stack size exceeded”)
>> e.stack lines according to editor = 10 frames
>> 
>> 2. Firefox
>> test reported reentry count = 222044
>> split(…).length = 129 (probably because there’s an extra newline in 
>> there somewhere)
>> e.stack lines according to editor = 128 frames
>> 
>> 3. Safari
>> test reported reentry count = 31701
>> split(…).length = 31722 (I don’t know why there’s a 21 frame 
>> discrepancy here.  I’ll debug this later)
>> e.stack lines according to editor = ??? frames (WebInspector hangs every 
>> time I try to scroll in it, let alone let me highlight and copy the stack 
>> trace.  So I gave up)
>> 
>> Assuming the test function frame is not significantly different in size for 
>> all browsers, it looks like:
>> 1. Chrome uses a much smaller stack (about 1/3 of our stack).
>> 2. Firefox uses a much larger stack (possibly the full machine stack), but 
>> caps its Error.stack to just 128 frames (possibly a hardcoded limit).
>> 
>> Mark
>> 
>> 
>>> 
>>>  - Maciej
>>> 
>>>> 
>>>> Does anyone object to us adopting Error.stackTraceLimit and setting the 
>>>> default to 10 to match Chrome?
>>>> 
>>>> Mark
>>>> 
>>>> 
>>>> 
>>>>> On Mar 16, 2017, at 11:29 PM, Geoffrey Garen <gga...@apple.com 
>>>>> <mailto:gga...@apple.com>> wrote:
>>>>> 
>>>>> Can you be more specific about the motivation here?
>>>>> 
>>>>> Do we have any motivating examples that will tell us wether time+memory 
>>>>> were unacceptable before this change, or are acceptable after this change?
>>>>> 
>>>>> In our motivating examples, does Safari use more time+memory than other 
>>>>> browsers? If so, how large of a stack do other browsers capture?
>>>>> 
>>>>> We already limit the size of the JavaScript stack to avoid performance 
>>>>> problems like the ones you mention in many other contexts. Why is that 
>>>>> limit not sufficient?
>>>>> 
>>>>> Did you consider implementing Chrome’s Error.stackTraceLimit behavior?
>>>>> 
>>>>> Geoff
>>>>> 
>>>>>> On Mar 16, 2017, at 10:09 PM, Mark Lam <mark@apple.com 
>>>>>> <mailto:mark@apple.com>> wrote:
>>>>>> 
>>>>>> Hi folks,
>>>>>> 
>>>>>> Currently, if we have an exception stack that is incredibly deep 
>>>>>> (especially for a StackOverflowError), JSC may end up thrashing memory 
>>>>>> just to capture the large stack trace in memory.This is bad for many 
>>>>>> reasons:
>>>>>> 
>>>>>> 1. the captured stack will take a lot of memory.
>>>>>> 2. capturing the stack may take a long time (due to memory thrashing) 
>>>>>> and makes for a bad user experience.
>>>>>> 3. if memory availability is low, capturing such a large stack may 
>>>>>> result in an OutOfMemoryError being thrown in its place.
>>>>>>   The OutOfMemoryError thrown there will also have the same problem with 
>>>>>> capturing such a large stack.
>>>>>> 4. most of the time, no one will look at the captured Error.stack anyway.
>>>>>> 
>>>>>> Since there isn’t a standard on what we really need to capture for 
>>>>>> Error.stack, I propose that we limit how much stack we capture to a 
>>>>>> practical size.  How about an Error.stack that consists of (1) the top N 
>>>>>> frames, (2) an ellipses, a

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

2017-03-17 Thread Geoffrey Garen
Thanks for the detailed write-up.

The main thing that sticks out to me in this data is that Safari defaults to 
capturing a stack that is, in the worst case, roughly 3000X larger than the 
stack in IE and Chrome. That’s a big difference. I think this could be a real 
website compatibility problem since an author who tested in IE or Chrome might 
not notice a repeatedly thrown exception, which could cause time or memory or 
even bandwidth problems (if the author phoned home with exception data) in 
Safari.

Since Chrome and IE have already adopted it, I like Error.stackTraceLimit, and 
I think we should propose standardizing it. (We can standardize 
Error.stackTraceLimit even before we fully standardize the text content of 
Error.stack.)

I think 10 is possibly an unnecessarily low default. Most stack traces are 
bigger than 10. 30 would still be two orders of magnitude better than the 
status quo. Even 50 or 100 might be OK, as long as your testing shows it’s not 
too expensive.

Elipsizing was a cool idea, but given the behavior of other browsers, I think 
it’s better to truncate Error.stack and consider elipsizing in Web Inspector, 
where presentation matters more and has less of an effect on web compatibility.

Geoff

> On Mar 17, 2017, at 11:09 AM, Mark Lam <mark@apple.com> wrote:
> 
> Thanks for the reminder to back observations up with data.  I was previously 
> running some tests that throws StackOverflowErrors a lot (which tainted my 
> perspective), and I made a hasty conclusion which isn’t good.  Anyway, here’s 
> the data using an instrumented VM to take some measurements and a simple test 
> program that recurses forever to throw a StackOverflowError (run on a MacPro):
> 
> 1. For a release build of jsc shell:
> Time to capture exception stack = 0.002807 sec
> Number of stack frames captured = 31722
> sizeof StackFrame = 24
> total memory consumed = ~761328 bytes.
> 
> 2. For a debug build of jsc shell:
> Time to capture exception stack = 0.052107 sec
> Number of stack frames captured = 31688
> sizeof StackFrame = 24
> total memory consumed = ~760512 bytes.
> 
> So, regarding performance, I was wrong.  The amount of time taken to capture 
> the entire JS stack each time is insignificant.
> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
> 
> Comparing browsers with their respective inspectors open:
> 
> 1. Chrome
> number of frames captured: 10
> length of e.stack string: 824 chars
> time to console.log e.stack: 0.27 seconds
> 
> 2. Firefox
> number of frames captured: 129
> length of e.stack string: 8831 chars
> time to console.log e.stack: 0.93 seconds
> 
> 3. Safari
> number of frames captured: 31722
> length of e.stack string: 218821 chars
> time to console.log e.stack: 50.8 seconds
> 
> 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
> simulate my proposal)
> number of frames captured: 201
> length of e.stack string: 13868 chars
> time to console.log e.stack: 1 second
> 
> With my proposal, the experience of printing Error.stack drops from 50.8 
> seconds to about 1 second.  The memory used for capturing the stack also 
> drops from ~760K to 5K.
> 
> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
> better solution than my proposal since it gives developers the ability to 
> capture more stack frames if they need it.  Chrome’s default 
> Error.stackTraceLimit appears to be 10.  MS appears to support it as well and 
> defaults to 10 
> (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript
>  
> <https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript>).
>   Firefox does now.
> 
> Does anyone object to us adopting Error.stackTraceLimit and setting the 
> default to 10 to match Chrome?
> 
> Mark
> 
> 
> 
>> On Mar 16, 2017, at 11:29 PM, Geoffrey Garen <gga...@apple.com 
>> <mailto:gga...@apple.com>> wrote:
>> 
>> Can you be more specific about the motivation here?
>> 
>> Do we have any motivating examples that will tell us wether time+memory were 
>> unacceptable before this change, or are acceptable after this change?
>> 
>> In our motivating examples, does Safari use more time+memory than other 
>> browsers? If so, how large of a stack do other browsers capture?
>> 
>> We already limit the size of the JavaScript stack to avoid performance 
>> problems like the ones you mention in many other contexts. Why is that limit 
>> not sufficient?
>> 
>> Did you consider implementing Chrome’s Error.stackTraceLimit behavi

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

2017-03-17 Thread Geoffrey Garen
Can you be more specific about the motivation here?

Do we have any motivating examples that will tell us wether time+memory were 
unacceptable before this change, or are acceptable after this change?

In our motivating examples, does Safari use more time+memory than other 
browsers? If so, how large of a stack do other browsers capture?

We already limit the size of the JavaScript stack to avoid performance problems 
like the ones you mention in many other contexts. Why is that limit not 
sufficient?

Did you consider implementing Chrome’s Error.stackTraceLimit behavior?

Geoff

> On Mar 16, 2017, at 10:09 PM, Mark Lam  wrote:
> 
> Hi folks,
> 
> Currently, if we have an exception stack that is incredibly deep (especially 
> for a StackOverflowError), JSC may end up thrashing memory just to capture 
> the large stack trace in memory.This is bad for many reasons:
> 
> 1. the captured stack will take a lot of memory.
> 2. capturing the stack may take a long time (due to memory thrashing) and 
> makes for a bad user experience.
> 3. if memory availability is low, capturing such a large stack may result in 
> an OutOfMemoryError being thrown in its place.
>The OutOfMemoryError thrown there will also have the same problem with 
> capturing such a large stack.
> 4. most of the time, no one will look at the captured Error.stack anyway.
> 
> Since there isn’t a standard on what we really need to capture for 
> Error.stack, I propose that we limit how much stack we capture to a practical 
> size.  How about an Error.stack that consists of (1) the top N frames, (2) an 
> ellipses, and (3) the bottom M frames?  If the number of frames on the stack 
> at the time of capture  is less or equal to than N + M frames, then 
> Error.stack will just show the whole stack with no ellipses.  For example, if 
> N is 4 and M is 2, the captured stack will look something like this:
> 
>  foo10001
>  foo1
>  foo
>  foo9998
>  …
>  foo1
>  foo0
> 
> If we pick a sufficient large number for N and M (I suggest 100 each), I 
> think this should provide sufficient context for debugging uses of 
> Error.stack, while keeping an upper bound on how much memory and time we 
> throw at capturing the exception stack.
> 
> My plan for implementing this is:
> 1. change Exception::finishCreation() to only capture the N and M frames, 
> plus possibly 1 ellipses placeholder in the between them.
> 2. change all clients of Exception::stack() to be able to recognize and 
> render the ellipses.
> 
> Does anyone object to doing this or have a compelling reason why this should 
> not be done?
> 
> Thanks.
> 
> Mark
> 
> 
> 
> ___
> 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] Why does RELEASE_ASSERT not have an error message?

2017-02-23 Thread Geoffrey Garen

> On Feb 22, 2017, at 12:16 PM, Filip Pizlo <fpi...@apple.com> wrote:
> 
> 
>> On Feb 22, 2017, at 11:58 AM, Geoffrey Garen <gga...@apple.com> wrote:
>> 
>> I’ve lost countless hours to investigating CrashTracers that would have been 
>> easy to solve if I had access to register state.
> 
> The current RELEASE_ASSERT means that every assertion in what the compiler 
> thinks is a function (i.e. some function and everything inlined into it) is 
> coalesced into a single trap site.  I’d like to understand how you use the 
> register state if you don’t even know which assertion you are at.

Not all functions suffer from this problem. Few enough functions suffer from 
this problem that I haven’t felt an urgent need to address it.

> I believe that if you do want to analyze register state, then switching back 
> to calling some function that prints out diagnostic information is strictly 
> better.  Sure, you get less register state, but at least you know where you 
> crashed.  Knowing where you crashed is much more important than knowing the 
> register state, since the register state is not useful if you don’t know 
> where you crashed.

See above.

Also, printed diagnostic information is not available in CrashTracer reports, 
while register state is.

> 
>> 
>> I also want the freedom to add RELEASE_ASSERT without ruining performance 
>> due to bad register allocation or making the code too large to inline. For 
>> example, hot paths in WTF::Vector use RELEASE_ASSERT.
> 
> Do we have data about the performance benefits of the current RELEASE_ASSERT 
> implementation?

Oliver needed it in order to turn on assertions in side Vector.h without 
regression. You can follow the svn / bugzilla history to find out more.

> 
>> 
>> Is some compromise solution possible?
>> 
>> Some options:
>> 
>> (1) Add a variant of RELEASE_ASSERT that takes a string and logs.
> 
> The point of C++ assert macros is that I don’t have to add a custom string.  
> I want a RELEASE_ASSERT macro that automatically stringifies the expression 
> and uses that as the string.

FWIW, all of the existing cases of dataLog followed by RELEASE_ASSERT that I 
could find wanted to log something other than just the expression — for 
example, a pointer value.

> If I had a choice between a RELEASE_ASSERT that can accurate report where it 
> crashed but sometimes trashes the register state, and a RELEASE_ASSERT that 
> always gives me the register state but cannot tell me which assert in the 
> function it’s coming from, then I would always choose the one that can tell 
> me where it crashed.  That’s much more important, and the register state is 
> not useful without that information.

I don’t think it’s helpful to conflate (a) I want a string message with (b) I 
want to solve a coalescing problem.

> 
>> 
>> (2) Change RELEASE_ASSERT to do the normal debug ASSERT thing in Debug 
>> builds. (There’s not much need to preserve register state in debug builds.)
> 
> That would be nice, but doesn’t make RELEASE_ASSERT useful for debugging 
> issues where timing is important.  I no longer use RELEASE_ASSERTS for those 
> kinds of assertions, because if I do it then I will never know where I 
> crashed.  So, I use the explicit:
> 
> if (!thing) {
>   dataLog(“…”);
>   RELEASE_ASSERT_NOT_REACHED();
> }

If asserts are generally set up to provide the extra data we want, and we just 
need a temporary change in assertion policy to satisfy a use case like this, 
that’s easy enough to achieve with a local configuration change to Assertions.h.

Geoff

> 
> -Filip
> 
> 
>> 
>> Geoff
>> 
>>> On Feb 22, 2017, at 11:09 AM, Filip Pizlo <fpi...@apple.com> wrote:
>>> 
>>> I disagree actually.  I've lost countless hours to converting this:
>>> 
>>> RELEASE_ASSERT(blah)
>>> 
>>> into this:
>>> 
>>> if (!blah) {
>>> dataLog("Reason why I crashed");
>>> RELEASE_ASSERT_NOT_REACHED();
>>> }
>>> 
>>> Look in the code - you'll find lots of stuff like this.
>>> 
>>> I don't think analyzing register state at crashes is more important than 
>>> keeping our code sane.
>>> 
>>> -Filip
>>> 
>>> 
>>>> On Feb 21, 2017, at 5:56 PM, Mark Lam <mark@apple.com> wrote:
>>>> 
>>>> Oh yeah, I forgot about that.  I think the register state is more 
>>>> important for crash analysis, especially if we can make sure that the 
>>>> compiler does not aggregate the int3s.  I’ll explore alternatives.
>>>> 
>>>>> On Feb 21, 2017, at 5:54 PM, S

Re: [webkit-dev] Why does RELEASE_ASSERT not have an error message?

2017-02-22 Thread Geoffrey Garen
I’ve lost countless hours to investigating CrashTracers that would have been 
easy to solve if I had access to register state.

I also want the freedom to add RELEASE_ASSERT without ruining performance due 
to bad register allocation or making the code too large to inline. For example, 
hot paths in WTF::Vector use RELEASE_ASSERT.

Is some compromise solution possible?

Some options:

(1) Add a variant of RELEASE_ASSERT that takes a string and logs.

(2) Change RELEASE_ASSERT to do the normal debug ASSERT thing in Debug builds. 
(There’s not much need to preserve register state in debug builds.)

Geoff

> On Feb 22, 2017, at 11:09 AM, Filip Pizlo  wrote:
> 
> I disagree actually.  I've lost countless hours to converting this:
> 
> RELEASE_ASSERT(blah)
> 
> into this:
> 
> if (!blah) {
>   dataLog("Reason why I crashed");
>   RELEASE_ASSERT_NOT_REACHED();
> }
> 
> Look in the code - you'll find lots of stuff like this.
> 
> I don't think analyzing register state at crashes is more important than 
> keeping our code sane.
> 
> -Filip
> 
> 
>> On Feb 21, 2017, at 5:56 PM, Mark Lam  wrote:
>> 
>> Oh yeah, I forgot about that.  I think the register state is more important 
>> for crash analysis, especially if we can make sure that the compiler does 
>> not aggregate the int3s.  I’ll explore alternatives.
>> 
>>> On Feb 21, 2017, at 5:54 PM, Saam barati  wrote:
>>> 
>>> I thought the main point of moving to SIGTRAP was to preserve register 
>>> state?
>>> 
>>> That said, there are probably places where we care more about the message 
>>> than the registers.
>>> 
>>> - Saam
>>> 
 On Feb 21, 2017, at 5:43 PM, Mark Lam  wrote:
 
 Is there a reason why RELEASE_ASSERT (and friends) does not call 
 WTFReportAssertionFailure() to report where the assertion occur?  Is this 
 purely to save memory?  svn blame tells me that it has been this way since 
 the introduction of RELEASE_ASSERT in r140577 many years ago.
 
 Would anyone object to adding a call to WTFReportAssertionFailure() in 
 RELEASE_ASSERT() like we do for ASSERT()?  One of the upside (side-effect) 
 of adding this call is that it appears to stop the compiler from 
 aggregating all the RELEASE_ASSERTS into a single code location, and this 
 will help with post-mortem crash debugging.
 
 Any thoughts?
 
 Mark
 
 ___
 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] CSS Parse error in element.

2017-02-03 Thread Geoffrey Garen
+Alex

> On Feb 3, 2017, at 1:17 AM, Atul Sowani  wrote:
> 
> At present I am focusing on CSSParser::findURI() particularly and 
> CSSParser::realLex() other related functionality in CSSParser.cpp - hope I am 
> on right track. ;-)
> 
> Please let me know if I should be looking at some other functionality as well 
> to resolve this issue.
> 
> Thanks!
> Atul.
> 
> On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani  > wrote:
> Hi,
> 
> I came across an issue in qtwebkit CSS parser while working on a PhantomJS 
> crash. The issue seems to be with parsing of  type 
> elements in an HTML page. What I observed is that the parser is trying to 
> interpret the value for href given inside double-quotes. The value contains a 
> "-" (e.g. "http://some.domain.com/some-page-etc-etc 
> "). The "-" sign is being 
> interpreted as minus and then things go wrong. In another case I found that 
> "\g" embedded in the value (e.g. 
> "http://some.domain.com/some-page/global/something 
> ") is also creating 
> issues. In essence, the parser is trying to interpret the value, which I 
> believe, it should not.
> 
> I am willing to dive further into it to debug and fix the issue, but looking 
> at the complexity and size of WebCore, I think I would benefit a lot to 
> expedite a fix, if I could get some tips about which code area/functionality 
> I should specifically focus in the WebCore. Looking forward to some help in 
> this regard.
> 
> Thanks,
> Atul.
> 
> 
> ___
> 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] [webkit-reviewers] usage of auto

2017-01-12 Thread Geoffrey Garen
>> My take-away from this discussion so far is that there is actually very 
>> little consensus on usage of auto, which means there’s probably very little 
>> room for actual style guideline rules.
>> 
>> I think there are two very limited rules that are probably not objectionable 
>> to anybody.
>> 
>> 1 - If you are using auto for a raw pointer type, you should use auto*
>> 2 - If you are using auto in a range-based for loop for values that aren’t 
>> pointers, you should use (const) auto&
> 
> In some cases you need a copy for the code to be correct. I understand why & 
> is often better for performance but there is a significant and dangerous 
> behavioral difference.
> 
> I agree with encouraging people to use auto& because it's usually ok, but I 
> disagree with mandating it because it's sometimes wrong. 

Seems like we could still have a style guideline in favor of these styles.

Style guidelines are always recommendations, which are of course not followed 
if they produce incorrect code. For example, it is S_OK to violate our camel 
case guidelines when interfacing with COM APIs.

I think Darin would also suggest:

1.5 - If you are using auto in a range-based for loop for values that are 
scalars, you should use auto.

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


Re: [webkit-dev] [webkit-reviewers] usage of auto

2017-01-12 Thread Geoffrey Garen
>> e.g. I think this is great:
>> auto ptr = std::make_unique(bar);
>> Proposed rule: if the type is obvious because it's on the line, then auto is 
>> good.
>> Similarly:
>> auto i = static_cast(j);
>> auto foo = make_foo();
>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
> I'm not sure I agree with this style. There are times where the type of an 
> auto variable is obvious-enough, but it's almost never more obvious than 
> actually writing out the types.

In the first case, static_cast, the type is written out on the same line. 
Same goes for other casts, make_unique, and so on. Would you accept auto in 
those cases? If not, what benefit do you get from seeing the type twice on one 
line?

I think the second and third cases are somewhat rare in WebKit, and I might 
agree against using auto. For example:

RefPtr thing;
auto* context = something.context();
context->setThing(thing.get()); // I need to research why context->thing is 
allowed to be a raw pointer, but I don’t know what context is.

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


Re: [webkit-dev] [webkit-reviewers] usage of auto

2017-01-11 Thread Geoffrey Garen
I’m open to auto, but skeptical.

(1) Research-ability. I read a lot of code that is new to me, that I have never 
written. I find type statements to be useful as documentation for where to look 
for more information about how data structures and algorithms relate to each 
other. Traversing a tree or list of data structures by type name while reading 
code is a common task for me. But I can’t select and search for auto, auto*, or 
auto&.

(2) Mechanics. It’s totally true that if you loop over one collection and put 
the values into another collection, subject to some filter, the types involved 
aren’t really interesting to reviewing the filter. But if you want to review 
low-level mechanics like object lifetime and thread safety, suddenly the types 
are really important. I think the “I changed RefPtr to auto and then crashed” 
examples in this thread are about mechanics.

I find it strange that, as JavaScript authors adopt tools like TypeScript 
because they find type-less programming to be unmaintainable, C++ authors move 
toward type-less programming. Perhaps the grass is always greener on the other 
side. Or perhaps we can strike a balance and put types where they help us.

Two arguments made in favor of auto don’t fully convince me:

(1) You were always able to hide the types of certain expressions. 

I’m hoping the point of this argument is not to say “in for a penny, in for a 
pound”, but rather to raise our awareness that we’ve been OK with certain 
type-less expressions all along. I agree: I'm OK with hiding types in some 
places, especially if surrounding code already provides some kind of type 
foothold.

At the same time, I sometimes break expressions into statements to improve 
clarity and research-ability or to achieve certain mechanics.

Maybe this answers Darin’s question:

> Here’s one thing to consider: Why is it important to see the type of 
> foundSource->value, but not important to see the type of shifts.take(source)? 
> In both cases they need to be Vector.

In the cited code, ‘shifts’ is declared as HashMap, 
and HashMap ’take' is well understood to return its value type, so no further 
comment about type is necessary for me on this line.

Following this logic, I might be OK with eliding the type of 
foundSource->value. But we’re starting to reach a limit. Each time we do this 
we create an auto link in the type chain. If I have to trace back three autos 
deep in order to understand a type, I’m gonna have a bad time. Each type 
declaration is a stopping point for research. Therefore, I don’t prefer the 
fully auto version of this code.

Following this logic, I would be OK with const auto& a little later in this 
algorithm:

> bool isRotate = false;
> for (const ShufflePair& pair : currentPairs) {
> if (pair.dst() == originalSrc) {
> isRotate = true;
> break;
> }
> }

Might as well use const auto& for ‘pair’: The type of currentPairs is 
well-documented locally. If currentPairs were a data member, and not declared 
in the same screenful of code, I would want to write out a type for ‘pair’. 
Otherwise, I would have to open another file to understand this line.

But somebody said we don’t like const auto&? Is this a gotcha somehow?

(2) You can’t be sure of the stated type, since a type conversion may have 
happened.

Knowing that a value is equivalent to a certain type still provides a foothold 
for research and understanding mechanics.

We only allow automatic type conversion when we consider types to be reasonably 
equivalent. We consider it bad style to convert willy-nilly, and we use the 
explicit keyword to avoid errant conversions. For example, we don’t allow 
RefPtr to automatically convert to raw pointer.

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


Re: [webkit-dev] Thread naming policy in WebKit

2017-01-05 Thread Geoffrey Garen
Alternatively, we could just change thread name from a char* to a struct { 
char*, char* } that contains a long name and a short name.

Geoff

> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
> 
>> 
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI > > wrote:
>> 
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler > > wrote:
>> I understand the appeal of “org.webkit” and structured names but personally 
>> I would prefer to read names that look like titles and are made up of words 
>> with spaces, like these:
>> 
>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>> “WebKit: JavaScript DFG Compiler” rather than “org.webkit.jsc.DFGCompiler”.
>> 
>> Not sure how well that would generalize to all the different names.
>> 
>> I like the idea of having a smart way of automatically making a shorter name 
>> for the platforms that have shorter length limits.
>> 
>> One interesting idea I've come up with is that,
>> 
>> 1. specifying "org.webkit.ImageDecoder"
>> 2. In Linux, we just use "ImageDecoder" part.
>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
> 
> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder” part 
> is ever going to be used?
> Is that because Windows could use “org.webkit.”?
> 
> Again, back to Darin’s point, I don’t see any particular value in ever seeing 
> “org.webkit.”
> 
> Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
> presumably separated on case-change, is problematic.
> 
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called, would 
> expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
> 
> —
> 
> Taking your proposal and running with it, I think we could do this:
> 
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
> 
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…" 
> 
> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
> 
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous 
> Disassembler"
> 
> Addendum: If we see value in having somethings flagged as “JSC” instead of 
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
> feature could be “WebKit. IndexedDB Server”
> 
> Thanks,
> ~Brady
> ___
> 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] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread Geoffrey Garen
EncodedJSValue was always just a work-around to convince the compiler to put a 
JSValue in registers (instead of on the stack, with different compilers 
disagreeing about where on the stack).

I agree with removing EncodedJSValue if possible.

Did something change to make this possible? For example, are you sure that 
Windows and 32bit are OK with this change?

I don’t understand why C linkage would affect things: Either the compiler puts 
structs in registers or it doesn’t.

Geoff

> On Jan 3, 2017, at 2:44 PM, Filip Pizlo  wrote:
> 
> I think that this is great!
> 
> I agree with the policy that we should use JSValue everywhere that it would 
> give us the same codegen/ABI (args in registers, return in registers, etc). 
> 
> -Filip
> 
> On Jan 3, 2017, at 14:33, Mark Lam  > wrote:
> 
>> Over the holiday period, I looked into the possibility of giving 
>> EncodedJSValue a default constructor (because I didn’t like having to return 
>> encodedJSValue() instead of { } in lots of places), and learned why we had 
>> EncodedJSValue in the first place (i.e. for C linkage).  This led me to 
>> discover (in my reading of the code) that we don’t really need to use 
>> EncodedJSValue for most of our host functions (those of type NativeFunction, 
>> GetValueFunc, and PutValueFunc).  
>> 
>> I propose that we switch to using JSValue directly where we can.  This has 
>> the benefit of:
>> 1. better type safety with the use of JSValue (EncodedJSValue is a int64_t 
>> typedef).
>> 2. more readable code (less marshaling back and forth with 
>> JSValue::encode()/decode()).
>> 
>> The patch for this change can be found here:
>> https://bugs.webkit.org/show_bug.cgi?id=166658 
>> 
>> 
>> Perf is neutral.  Any opinions?
>> 
>> Thanks.
>> 
>> Mark
>> ___
>> 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] Please hold off on commits

2016-11-08 Thread Geoffrey Garen
I’m sorry to say that, as of this morning, we’re still holding off on commits.

EWS and some Mac performance bots are back online, but some Mac performance 
bots and all iOS performance bots are still down.

Geoff

> On Nov 5, 2016, at 12:23 PM, Maciej Stachowiak  wrote:
> 
> 
> Hello everyone,
> 
> At Apple, we are experiencing an unplanned outage in our continuous 
> integration lab. This interferes with proper functioning buildbots, 
> performance tests and EWS.
> Currently we expect the outage will last throughout the weekend and possibly 
> into early next week.
> 
> Last time we had a lengthy testing outage, many regressions crept into the 
> tree and it took a while to get them all resolved. All of us at Apple are 
> holding off on commits. We're asking other WebKit community members to be the 
> same.
> 
> If the outage doesn't seem likely to be resolved soon by tomorrow, we'll 
> likely set the SVN server to temporarily reject commits.
> 
> I apologize for the inconvenience. We are doing our utmost to get the service 
> outage resolved.
> 
> Regards,
> Maciej
> 
> ___
> 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] Asserting versus throwing in internals and testRunner objects

2016-09-23 Thread Geoffrey Garen
I vote for throwing a JS exception.

In my experience, tests that crash are harder to deal with than tests that 
throw JS exceptions. A backtrace is a less informative than the message “you 
called internals.X without a frame”. Symbolication takes a long time. And 
sometimes we have trouble associating crash logs with specific tests.

Geoff

> On Sep 23, 2016, at 2:25 PM, Ryosuke Niwa  wrote:
> 
> Hi all,
> 
> In https://bugs.webkit.org/show_bug.cgi?id=161919, a question was
> raised as to what would be the best practice when one of internals or
> testRunner method is called at an undesirable timing or wrong
> arguments.  The case in question was about calling it on a document
> without a frame when the method required a frame.
> 
> What would be the desired outcome of making such a method call?
> Should we be asserting it and crashing the process?  Or should we be
> throwing an exception?
> 
> - R. Niwa
> ___
> 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] Terminology for giving up ownership: take, release, move

2016-09-06 Thread Geoffrey Garen
“take” grinds my gears too — though I’ve gotten used to it, more or less.

I read “object.verb()” as a command, “verb”, directed at “object” (or sometimes 
as a question, “verb?”, directed at “object”). I think most APIs are phrased 
this way. And if I were Antonin Scalia, I would make the originalist argument 
that Smalltalk originally defined a method in object-oriented programming as a 
message to a receiver — not a message about a sender.

> In the context of a container, take() sort of makes sense by parallel to 
> get(). Though get() could be interpreted as either what the caller is doing 
> or what the callee is doing.
> 
> In other words, you could say that in the code below, function something gets 
> an item from the collection. In that sense, take() is a parallel construct. 
> Of course, you could instead say that function something asks collection to 
> get an item. That's what makes take() not make sense. But I am not sure 
> release() makes sense either way, for a collection. It conveys letting go of 
> the item but doesn't seem to convey fetching in the sake way get() or take() 
> do. I don't think move() would be right in this context either.
> 
> function something(Collection& collection, Key& key)
> {
>   doSomething(collection.get(key))
> }

Though it is possible to read “get” in this context as “I get from collection”, 
I think it is more natural to read “get” as a command: “collection, get this 
for me”. Other access verbs on collections, such as “find”, “add”, and 
“remove”, establish this pattern.

> Given that explanation, I think a possible direction is to rename the smart 
> pointer release() operation to take(). Many of our smart pointers already 
> have a get(). And the idea of taking the underlying value from a smart 
> pointer kind of makes sense, even though it is caller-perspective.

I’ve gotten used to “take", so I won’t call it pure applesauce, but it’s not my 
preference.

My favorite suggestion so far is “move”. The C++ standard helps make this a 
good word because it introduces as terms of art std::move and “move” 
constructors. But perhaps it is bad for a function named “move” not to return 
an rvalue reference. For example, one might object to 
“std::move(collection.move(key))”. Why the double move?

My second favorite suggestion is “release”. It matches a term of art in std 
smart pointers and it’s pretty clear.

My third favorite suggestion is “remove”. For collections, “remove” is just 
plain clearer. But “remove” is worse for non-collection value types like smart 
pointers because we “move” values in C++ — we do not “remove” them.

There are some good thesaurus words like cede or doff or discharge but they all 
lack familiarity as terms of art.

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


Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

2016-05-23 Thread Geoffrey Garen
>> Can we go with “WallClock” and “MonotonicClock” instead of “WallTime” and 
>> “MonotonicTime"? Clock is a nice clear noun. Also, time is an illusion 
>> caused by parallax in the astral plane.
> 
> I think time is the right term. "3pm" is a "time", not a "clock". Also 42 
> seconds since monotonic epoch is a monotonic time, not a monotonic clock. 

Hmmm… I think I read your original proposal wrong.

Sure, Seconds, MonotonicTime and WallTime are all times.

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


Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

2016-05-23 Thread Geoffrey Garen
> 3 - There exists a solution - non-templated custom classes - that removes 
> both classes of subtle bugs, without the template creep.

Hard to argue with this.

Can we go with “WallClock” and “MonotonicClock” instead of “WallTime” and 
“MonotonicTime"? Clock is a nice clear noun. Also, time is an illusion caused 
by parallax in the astral plane.

Geoff

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


Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

2016-05-23 Thread Geoffrey Garen
Since double is not a user-defined type, my understanding is that your template 
specializations in the std namespace are undefined behavior.

Geoff

> On May 22, 2016, at 10:46 PM, Michal Debski  wrote:
> 
> Hi,
>  
> sorry but this really bugs me. Isn't this enough?
>  
> namespace WTF {
> 
> using nanoseconds = std::chrono::duration;
> using microseconds = std::chrono::duration;
> using milliseconds = std::chrono::duration;
> using seconds = std::chrono::duration;
> using minutes = std::chrono::duration>;
> using hours = std::chrono::duration>;
> 
> template 
> std::chrono::time_point now()
> {
> return Clock::now();
> }
> 
> }
>  
> and forbid using std::chrono::clock::now()/durations with check-style. It 
> seems like the best of both worlds. Oh and the infinity:
>  
> namespace std {
> namespace chrono {
> 
> template<>
> struct duration_values {
> static constexpr double min() { return 
> -std::numeric_limits::infinity(); }
> static constexpr double zero() { return .0; }
> static constexpr double max() { return 
> std::numeric_limits::infinity(); }
> };
> 
> }
> }
>  
> Best regards,
> Michal Debski
>  
> --- Original Message ---
> Sender : Filip Pizlo>
> Date : May 23, 2016 02:41 (GMT+01:00)
> Title : [webkit-dev] RFC: stop using std::chrono, go back to using doubles 
> for time
>  
> Hi everyone! 
> 
> I’d like us to stop using std::chrono and go back to using doubles for time.  
> First I list the things that I think we wanted to get from std::chrono - the 
> reasons why we started switching to it in the first place.  Then I list some 
> disadvantages of std::chrono that we've seen from fixing std::chrono-based 
> code.  Finally I propose some options for how to use doubles for time.
> 
> Why we switched to std::chrono
> 
> A year ago we started using std::chrono for measuring time.  std::chrono has 
> a rich typesystem for expressing many different kinds of time.  For example, 
> you can distinguish between an absolute point in time and a relative time.  
> And you can distinguish between different units, like nanoseconds, 
> milliseconds, etc.
> 
> Before this, we used doubles for time.  std::chrono’s advantages over doubles 
> are:
> 
> Easy to remember what unit is used: We sometimes used doubles for 
> milliseconds and sometimes for seconds.  std::chrono prevents you from 
> getting the two confused.
> 
> Easy to remember what kind of clock is used: We sometimes use the monotonic 
> clock and sometimes the wall clock (aka the real time clock).  Bad things 
> would happen if we passed a time measured using the monotonic clock to 
> functions that expected time measured using the wall clock, and vice-versa.  
> I know that I’ve made this mistake in the past, and it can be painful to 
> debug.
> 
> In short, std::chrono uses compile-time type checking to catch some bugs.
> 
> Disadvantages of using std::chrono
> 
> We’ve seen some problems with std::chrono, and I think that the problems 
> outweigh the advantages.  std::chrono suffers from a heavily templatized API 
> that results in template creep in our own internal APIs.  std::chrono’s 
> default of integers without overflow protection means that math involving 
> std::chrono is inherently more dangerous than math involving double.  This is 
> particularly bad when we use time to speak about timeouts.
> 
> Too many templates: std::chrono uses templates heavily.  It’s overkill for 
> measuring time.  This leads to verbosity and template creep throughout common 
> algorithms that take time as an argument.  For example if we use doubles, a 
> method for sleeping for a second might look like sleepForSeconds(double).  
> This works even if someone wants to sleep for a nanoseconds, since 0.01 
> is easy to represent using a double.  Also, multiplying or dividing a double 
> by a small constant factor (1,000,000,000 is small by double standards) is 
> virtually guaranteed to avoid any loss of precision.  But as soon as such a 
> utility gets std::chronified, it becomes a template.  This is because you 
> cannot have sleepFor(std::chrono::seconds), since that wouldn’t allow you to 
> represent fractions of seconds.  This brings me to my next point.
> 
> Overflow danger: std::chrono is based on integers and its math methods do not 
> support overflow protection.  This has led to serious bugs like 
> https://bugs.webkit.org/show_bug.cgi?id=157924 
> .  This cancels out the 
> “remember what unit is used” benefit cited above.  It’s true that I know what 
> type of time I have, but as soon as I duration_cast it to another unit, I may 
> overflow.  The type system does not help!  This is insane: std::chrono 
> requires you to do more work when writing multi-unit code, so that you 
> satisfy the 

Re: [webkit-dev] Importing Test262 into WebKit

2016-05-12 Thread Geoffrey Garen
Is that 20min even when running in parallel (i.e., about 80min when running 
serially)?

That’s…. a lot. How much time is that per test?

Geoff

> On May 12, 2016, at 4:02 PM, Keith Miller  wrote:
> 
> Hi everyone,
> 
> For those of you that have not already heard of Test262, it is a continually 
> updated conformance test suite for upcoming ECMAScript standards 
> (https://github.com/tc39/test262). I think it’s in our best interest to 
> include the test suite in our normal testing infrastructure for 
> JavaScriptCore. The current plan is to only run the Test262 tests when 
> running run-javascript-core tests. The test suite is fairly large (~15000 
> tests) and the last time I ran it, it took about ~15-20 minutes to run. Are 
> there any questions or concerns with this proposal?
> 
> Cheers,
> Keith
> ___
> 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] Build slave for JSCOnly Linux MIPS

2016-04-18 Thread Geoffrey Garen

> On Apr 18, 2016, at 2:08 PM, Michael Catanzaro  wrote:
> 
> On Mon, 2016-04-18 at 22:36 +0300, Konstantin Tokarev wrote:
>> Are there any objections for lowering GCC requirement from 4.9.0 to
>> 4.8.4 (only for JavaScriptCore without B3)? I'm going to fix arising
>> compilation errors myself.
> 
> I've been kinda hoping to do this regardless, since you started
> contributing GCC 4.8 buildfixes. GCC 4.8 is still being used by a
> prominent distributor that's recently started releasing occasional
> WebKit updates. I worked on downstream patches to remove the GCC 4.9
> requirement so that their users can get WebKit updates. Since
> increasing our GCC requirement past the GCC version included in a
> distribution just guarantees users will never receive WebKit security
> updates, we need to recognize that we moved too quickly in increasing
> our requirement to GCC 4.9. (At the time I thought this was OK, but I
> was wrong.) We'll need to be more careful in the future when bumping
> our GCC requirement, lest we leave a large segment of users stuck on
> ancient versions of WebKit.

GCC 4.8 is three years old.

I don’t think we should put a three year hold on all current and future C++ 
language features.

Vendors that want to ship security updates to old, stable OS’s should maintain 
a branch that cherry-picks fixes from trunk and applies build fixes as 
necessary, rather than holding back development in trunk.

> It's unfortunate as of course we want to be able to use new language
> features, but we need to balance this with the desire to ensure our
> updates reach users.

I don’t think that shipping trunk as a security update on very old platforms is 
a viable strategy.

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


Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

2016-04-18 Thread Geoffrey Garen
>> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>> errors myself.

Yes.

We want to move forward in C++ language support, not backward.

Any platform not worthy of native compiler development is, a fortiori, also not 
worthy of JSC compiler development.

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


Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

2016-03-31 Thread Geoffrey Garen
+1

Geoff

> On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak  wrote:
> 
> 
> The recently released Safari Technology Preview has gotten more people living 
> on builds close to trunk, which is cool. Some people pointing out that the 
> current state of Fetch API causes problems - it's not quite complete enough 
> for real web apps that want to use it, but its presence breaks the detection 
> that would substitute a polypill.
> 
> I'd like to suggest that it should be disabled until it's complete enough to 
> work. I would propose a runtime flag instead of compile-time so it can 
> continue to be tested by our regression tests while it's getting finished up.
> 
> Regards,
> Maciej
> 
> ___
> 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] Mac CMake

2016-03-19 Thread Geoffrey Garen
> Just out of curiosity, is there any chance that Apple Mac WebKit
> will be migrated to cmake within the foreseeable future?

Based on initial experiments, I'm interested in CMake.

We (Alex, really) haven’t had the time to finish the Mac CMake build and/or do 
a complete head-to-head comparison with Xcode.

I would love to see a head-to-head comparison, if someone has time to make it 
happen. I see potential benefits to having a shared build system that is fast.

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


Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

2016-03-03 Thread Geoffrey Garen
I volunteer for any future needs in the physical restraint department -- but in 
this case, I think (3) sounds like a good idea.

Geoff

> On Mar 3, 2016, at 11:35 AM, Darin Adler  wrote:
> 
> OK!
> 
> Do we have volunteers to:
> 
> 1) update the style guide webpage
> 2) update check-webkit-style
> 3) physically restrain me from turning do-webcore-rename into a perl script 
> that does this all the code in the entire source tree all at one go, since 
> that would be a bad idea, right?
> 
> — 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


Re: [webkit-dev] Change WTFCrash to not trash the crash site register state.

2016-02-09 Thread Geoffrey Garen
I like this change.

Perhaps all ports can adopt this behavior. 

Geoff

> On Feb 8, 2016, at 11:55 AM, Mark Lam  wrote:
> 
> Hi WebKit folks,
> 
> For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s 
> implementation into an inlined function that has a single inlined asm 
> statement that issues a breakpoint trap.  The intent is to crash directly in 
> the caller’s frame and preserve the register values at the time of the crash. 
>  As a result, for non-debug OS(DARWIN) builds, crashes due to failed 
> RELEASE_ASSERTs will now show up in crash reports as crashing due to 
> EXC_BREAKPOINT (SIGTRAP) instead of a EXC_BAD_ACCESS (SIGSEGV) on address 
> 0xbbadbeef.
> 
> This is in contrast to the current implementation where WTFCrash() is a 
> function that calls a lot of handler / callback functions before actually 
> crashing.  As a result, by the time it crashes, the caller’s register values 
> has most likely been trashed by all the work that the WTFCrash and the 
> handlers / callbacks do.  The register values in the captured crash report 
> will, therefore, no longer be useful for crash site analysis. 
> 
> You can find the patch for this change at 
> https://bugs.webkit.org/show_bug.cgi?id=153996.  This change will only be 
> applied for non-debug OS(DARWIN) builds for now.  I’m leaving all other build 
> build configurations with the existing WTFCrash() implementation and behavior.
> 
> Does anyone have any opinion / feedback on this change?
> 
> Thanks.
> 
> Regards,
> Mark
> 
> ___
> 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
> 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 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


[webkit-dev] The great commit queue experiment

2015-11-12 Thread Geoffrey Garen
Hi folks.

A bunch of us at the WebKit Contributors Meeting decided that we will spend the 
next week landing 100% of our patches through the commit queue. Please feel 
free to play along at home.

If we see problems, we’ll document our experiences here:

This is why I love or hate the commit queue
https://bugs.webkit.org/show_bug.cgi?id=151239

Hopefully this will help us prioritize improvements in the commit queue, if any 
are needed.

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


Re: [webkit-dev] Thought about Nix JavaScriptCore port

2015-11-11 Thread Geoffrey Garen
I think it would be nice to avoid tying the Nix build to update-webkitgtk-libs, 
since part of the stated goal is platform freedom.

Geoff

> On Nov 11, 2015, at 2:15 AM, Sergio Villar Senin  wrote:
> 
> On 11/11/15 08:04, Yusuke SUZUKI wrote:
>> Hello WebKittens,
>> 
>> JavaScriptCore use in non-OSX environment looks emerging[1].
>> In addition to that, sometimes, people would like to build
>> JavaScriptCore to see what is happning in JavaScriptCore development[2].
>> However, if you don't have an OSX machine, it is a little bit difficult.
>> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
>> But it involves many dependencies (Mesa, glib etc.), that are not
>> necessary for JavaScriptCore and this is a barrier to join JSC
>> development from non OSX world.
> 
> The gtk port has several external dependencies as any other port and
> indeed most of them are not needed for building JSC. However I don't see
> those dependencies being a barrier, mainly because we build them using a
> jhbuild environment, so even if your distro don't provide the required
> dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.
> 
> Do you have issues doing that?
> 
> BR
> ___
> 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] Mac CMake

2015-10-30 Thread Geoffrey Garen

> On Oct 30, 2015, at 2:17 PM, Alex Christensen  wrote:
> 
> I got the Mac CMake build to the point where it can compile and link 
> frameworks successfully.  We will get a buildbot up soon, but in the meantime 
> please try to add and remove files in the CMake build.Let me know if you have 
> any questions or concerns or want to help out.  I don’t think it can be used 
> to run Safari yet, but that’s hopefully coming soon.
> 
> If you want to try it out, run this command:
> Tools/Scripts/build-webkit --cmake
> 
> Alex
> ___
> 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] Using JavaScriptCore in an audio context

2015-09-23 Thread Geoffrey Garen
> A more general question could be : would Apple allow applications developers 
> to use the fantastic power of LLVM tools and libraries in a "safe" way ? That 
> would be an interesting line of work…

That’s not a question for the webkit-dev list.

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


Re: [webkit-dev] (Legacy 2.1.1) LLINT: _llint_program_prologue CodeBlock::m_instructions[0] is NULL

2015-08-26 Thread Geoffrey Garen
The CodeBlock constructor is responsible for filling m_instructions. I’d start 
there.

Geoff

 On Aug 26, 2015, at 9:46 AM, Bryan Woodruff bryan.woodr...@boxspy.com wrote:
 
 Apologies in advance for cross-posting – not seeing any activity on 
 webkit-help.
  
 Caveat: Due to divergence in the code base and the target platform, I’m 
 working with an older port based on v2.1.1.  But, I believe my question is 
 broad enough that someone may be able to help point me in the right area.
  
 I’m enabling LLINT which was not enabled for the port we’re working with in 
 this version.   In the dispatch to llint_program_prologue, the 
 CodeBlock.m_instructions[0] points to the value 0 which results into a jmp to 
 0 and a subsequent access violation.
  
 I’m looking to understand what conditions cause CodeBlock.m_instructions[0] 
 to not point to code.   Both JIT and LLINT are enabled.
  
 JSC::prepareForExecution builds a CTI stub with programEntryThunkGenerator, 
 the prologue thunk executes and lands in the prologue code.  I verified that 
 the CodeBlock processed in prologue is the CodeBlock set up by this stack:
  
 x!JSC::prepareForExecutionJSC::ProgramCodeBlock(JSC::ExecState *, 
 WTF::OwnPtrJSC::ProgramCodeBlock  {...}, JSC::JITCode  {...}, 
 JSC::JITCode::JITType BaselineJIT, unsigned int) executionharness.h line 42
 x!JSC::ProgramExecutable::compileInternal(JSC::ExecState *, JSC::JSScope *, 
 JSC::JITCode::JITType BaselineJIT, unsigned int) executable.cpp line 328 + 19 
 bytes
 x!JSC::ProgramExecutable::compile(JSC::ExecState *, JSC::JSScope *) 
 executable.h line 514 + 19 bytes
  
 Note that this code path is not taken as the profiler is not enabled, I’m not 
 clear as to the design if this would impact this 0 index of m_instructions or 
 not.
  
 if (exec-vm().m_perBytecodeProfiler)
 
 exec-vm().m_perBytecodeProfiler-ensureBytecodesFor(codeBlock.get());
  
 After the prepareForExecution and going through the thunk, it’s the 
 processing of the CodeBlock that lands the instruction pointer at 0.  The 
 offset of m_instructions looks correct comparing the offset with other 
 assembly generated for other modules (including CodeBlock.cpp itself).   
 Inspecting the CodeBlock object and m_instructions[0] verifies it has a 0 in 
 this entry.   I am assuming this is unexpected – but I don’t understand where 
 this is supposed to be set up when tracing step-by-step through this code 
 path.
  
 Any suggestions/pointers appreciated.
  
 Thanks!
  
  
 _llint_program_prologue:
 prologue(notFunctionCodeBlockGetter, notFunctionCodeBlockSetter, 
 _llint_entry_osr, _llint_trace_prologue)
 dispatch(0)
  
  
 # Set up the PC.
if JSVALUE64
 loadp CodeBlock::m_instructions[t1], PB
 move 0, PC
 else
 loadp CodeBlock::m_instructions[t1], PC
 end
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 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] [webkit-changes] [187867] trunk/Tools

2015-08-04 Thread Geoffrey Garen
Oops!

I forgot that we had already gone through the nomination process for Saam.

Sam and I were talking about making Saam a reviewer right when you landed this 
patch. We counted his patches at 75, though, and we thought we couldn’t 
nominate him yet.

It looks like we miscounted, though, and Saam’s true patch count is 91.

Geoff

 On Aug 4, 2015, at 11:07 AM, Geoffrey Garen gga...@apple.com wrote:
 
 Mark,
 
 While I am excited about Saam becoming a reviewer soon, this is the wrong 
 process.
 
 Please roll out this change and follow the procedure explained at 
 https://www.webkit.org/coding/commit-review-policy.html 
 https://www.webkit.org/coding/commit-review-policy.html.
 
 Thanks,
 Geoff
 
 On Aug 4, 2015, at 11:03 AM, mark@apple.com mailto:mark@apple.com 
 wrote:
 
 Revision
 187867 http://trac.webkit.org/projects/webkit/changeset/187867Author
 mark@apple.com mailto:mark@apple.comDate
 2015-08-04 11:03:30 -0700 (Tue, 04 Aug 2015)
 Log Message
 
 Unreviewed. Make Saam Barati a WebKit reviewer.
 
 * Scripts/webkitpy/common/config/contributors.json:
 Modified Paths
 
 trunk/Tools/ChangeLog x-msg://8/#trunkToolsChangeLog
 trunk/Tools/Scripts/webkitpy/common/config/contributors.json 
 x-msg://8/#trunkToolsScriptswebkitpycommonconfigcontributorsjson
 Diff
 
  Modified: trunk/Tools/ChangeLog (187866 = 187867)
 
 --- trunk/Tools/ChangeLog2015-08-04 17:48:59 UTC (rev 187866)
 +++ trunk/Tools/ChangeLog2015-08-04 18:03:30 UTC (rev 187867)
 @@ -1,3 +1,9 @@
 +2015-08-04  Mark Lam  mark@apple.com mailto:mark@apple.com
 +
 +Unreviewed. Make Saam Barati a WebKit reviewer.
 +
 +* Scripts/webkitpy/common/config/contributors.json:
 +
  2015-08-04  Xabier Rodriguez Calvar  calva...@igalia.com 
 mailto:calva...@igalia.com
  
  Unreviewed, updated Streams API watchlist.
  Modified: trunk/Tools/Scripts/webkitpy/common/config/contributors.json 
 (187866 = 187867)
 
 --- trunk/Tools/Scripts/webkitpy/common/config/contributors.json 
 2015-08-04 17:48:59 UTC (rev 187866)
 +++ trunk/Tools/Scripts/webkitpy/common/config/contributors.json 
 2015-08-04 18:03:30 UTC (rev 187867)
 @@ -2450,14 +2450,6 @@
  ryuan
   ]
},
 -  Saam Barati : {
 - emails : [
 -saambara...@gmail.com mailto:saambara...@gmail.com
 - ],
 - nicks : [
 -saamyjoon
 - ]
 -  },
Sadrul Habib Chowdhury : {
   emails : [
  sad...@chromium.org mailto:sad...@chromium.org
 @@ -4663,6 +4655,14 @@
  weinig
   ]
},
 +  Saam Barati : {
 + emails : [
 +saambara...@gmail.com mailto:saambara...@gmail.com
 + ],
 + nicks : [
 +saamyjoon
 + ]
 +  },
Sergio Villar Senin : {
   emails : [
  svil...@igalia.com mailto:svil...@igalia.com,
 ___
 webkit-changes mailing list
 webkit-chan...@lists.webkit.org mailto:webkit-chan...@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-changes 
 https://lists.webkit.org/mailman/listinfo/webkit-changes

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


Re: [webkit-dev] [webkit-changes] [187867] trunk/Tools

2015-08-04 Thread Geoffrey Garen
Mark,

While I am excited about Saam becoming a reviewer soon, this is the wrong 
process.

Please roll out this change and follow the procedure explained at 
https://www.webkit.org/coding/commit-review-policy.html.

Thanks,
Geoff

 On Aug 4, 2015, at 11:03 AM, mark@apple.com wrote:
 
 Revision
 187867 http://trac.webkit.org/projects/webkit/changeset/187867Author
 mark@apple.com mailto:mark@apple.comDate
 2015-08-04 11:03:30 -0700 (Tue, 04 Aug 2015)
 Log Message
 
 Unreviewed. Make Saam Barati a WebKit reviewer.
 
 * Scripts/webkitpy/common/config/contributors.json:
 Modified Paths
 
 trunk/Tools/ChangeLog x-msg://8/#trunkToolsChangeLog
 trunk/Tools/Scripts/webkitpy/common/config/contributors.json 
 x-msg://8/#trunkToolsScriptswebkitpycommonconfigcontributorsjson
 Diff
 
  Modified: trunk/Tools/ChangeLog (187866 = 187867)
 
 --- trunk/Tools/ChangeLog 2015-08-04 17:48:59 UTC (rev 187866)
 +++ trunk/Tools/ChangeLog 2015-08-04 18:03:30 UTC (rev 187867)
 @@ -1,3 +1,9 @@
 +2015-08-04  Mark Lam  mark@apple.com mailto:mark@apple.com
 +
 +Unreviewed. Make Saam Barati a WebKit reviewer.
 +
 +* Scripts/webkitpy/common/config/contributors.json:
 +
  2015-08-04  Xabier Rodriguez Calvar  calva...@igalia.com 
 mailto:calva...@igalia.com
  
  Unreviewed, updated Streams API watchlist.
  Modified: trunk/Tools/Scripts/webkitpy/common/config/contributors.json 
 (187866 = 187867)
 
 --- trunk/Tools/Scripts/webkitpy/common/config/contributors.json  
 2015-08-04 17:48:59 UTC (rev 187866)
 +++ trunk/Tools/Scripts/webkitpy/common/config/contributors.json  
 2015-08-04 18:03:30 UTC (rev 187867)
 @@ -2450,14 +2450,6 @@
  ryuan
   ]
},
 -  Saam Barati : {
 - emails : [
 -saambara...@gmail.com mailto:saambara...@gmail.com
 - ],
 - nicks : [
 -saamyjoon
 - ]
 -  },
Sadrul Habib Chowdhury : {
   emails : [
  sad...@chromium.org mailto:sad...@chromium.org
 @@ -4663,6 +4655,14 @@
  weinig
   ]
},
 +  Saam Barati : {
 + emails : [
 +saambara...@gmail.com mailto:saambara...@gmail.com
 + ],
 + nicks : [
 +saamyjoon
 + ]
 +  },
Sergio Villar Senin : {
   emails : [
  svil...@igalia.com mailto:svil...@igalia.com,
 ___
 webkit-changes mailing list
 webkit-chan...@lists.webkit.org mailto:webkit-chan...@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-changes 
 https://lists.webkit.org/mailman/listinfo/webkit-changes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Contributing to webkit Open Source project

2015-08-03 Thread Geoffrey Garen
Hi Mukesh.

Welcome to the project.

How did your project turn out? If it was successful, the best place to start is 
to post patches to bugs.webkit.org http://bugs.webkit.org/.

Another important project we’re working on right now is finishing our 
implementation of ES6. A quick way to get a list of missing features is to 
navigate to https://kangax.github.io/compat-table/es6/ 
https://kangax.github.io/compat-table/es6/ using a WebKit nightly build.

Regards,
Geoff

 On Aug 2, 2015, at 3:12 PM, Mukesh Kumar Tiwari mh...@cornell.edu wrote:
 
 Hi,
 
 I am graduate from Cornell willing to contribute to WebKit Open Source 
 project. During the college, I have worked on a project to optimize LLVM 
 backend of the Webkit and have a decent knowledge of the FTL Layer. I would 
 like to gain more knowledge by contributing to WebKit Project. Please guide 
 me on where to begin with.
 
 Thanks and Regards,
 Mukesh Kumar Tiwari
 Software Development Engineer
 Amazon.com
 ___
 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] Infinite JavaScript loop blocks the MiniBrowser

2015-07-28 Thread Geoffrey Garen
Mark, do you know how to restart JavaScript after it has reached a watchdog 
time limit?

Geoff

 On Jul 28, 2015, at 9:09 AM, Pascal Jacquemart p.jacquem...@samsung.com 
 wrote:
 
 Hello,
 
 I am trying to protect the MiniBrowser from executing faulty JavaScript code 
 taking too much time / CPU. All browsers normally raise a pop-up allowing the 
 user to stop the script and run away. 
 But MiniBrowser does not seem to have such feature. It is just stuck forever 
 ;-(
 
 After a little digging I found this JSC API: 
 JSContextGroupSetExecutionTimeLimit()
 I had to implement a JSC Watchdog back-end because it is not implemented for 
 EFL, fair enough - https://bugs.webkit.org/show_bug.cgi?id=147107 
 https://bugs.webkit.org/show_bug.cgi?id=147107 (ongoing)
 
 Now the JSContextGroupSetExecutionTimeLimit() have the expected behaviour.
 I can stop the JavaScript execution and run away... Great but the big problem 
 now is that the JavaScript won't restart. Even while loading other pages, the 
 JavaScript remains disabled.
 
 If you have any hints about this, I would be grateful.
 How to restart JavaScript execution? Where to look? Is it an EFL bug?
 
 Thanks,   Pascal Jacquemart
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 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] JSC framework API proposal: setting a handler for enqueuing tasks

2015-07-06 Thread Geoffrey Garen
I’m suggesting a default runloop for non-web content.

I haven’t read through the details of integrating with the web content 
definition of micro task.

Geoff

 On Jul 6, 2015, at 4:44 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 Should JS be defining an event loop abstraction that WebCore then uses? That 
 would be weird, because the required behavior of the even loop in web content 
 is chock full of issues that are not at all related to JavaScript. JSC 
 doesn't even know enough to run microtasks at all the right times (from 
 reading the spec it seems that way, at least) for the Web case. Or are you 
 saying it would have a fallback runloop for non-Web contents?
 
 Regards,
 Maciej
 
 On Jul 6, 2015, at 3:24 PM, Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 
 I think it would be better for JavaScriptCore to handle micro tasks natively.
 
 It’s not so great for each client to need to reinvent the microtask runloop 
 abstraction.
 
 Geoff
 
 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com 
 mailto:utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private function, 
 @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no 
 event loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto: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] JSC framework API proposal: setting a handler for enqueuing tasks

2015-07-06 Thread Geoffrey Garen
I think it would be better for JavaScriptCore to handle micro tasks natively.

It’s not so great for each client to need to reinvent the microtask runloop 
abstraction.

Geoff

 On Jul 6, 2015, at 10:05 AM, Yusuke SUZUKI utatane@gmail.com wrote:
 
 Hi WebKittens,
 
 I've landed the update of the ES6 Promise implementation.
 Through this work, I've experimentally added the internal private function, 
 @enqueueJob(JS function, JS array for arguments).
 This is corresponding to the ES6 spec EnqueueJob[1].
 
 This EnqueueJob handler is now tightly integrated with WebCore's microtask 
 infrastructure. So in JSC framework side, we cannot use this function.
 As a result, current JSC framework disables Promise because there's no event 
 loop abstraction.
 
 So I propose the API configuring euqueueJob handler into JSC VM (That 
 corresponds to the Realm in ECMA spec).
 
 Like,
 
 void JSContextGroupSetEnqueueJobCallback(JSContextGroupRef, 
 JSEnqueueJobCallback, void* callbackData);
 
 What do you think about this?
 
 [1]: http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob 
 http://ecma-international.org/ecma-262/6.0/#sec-enqueuejob
 
 Best Regards,
 Yusuke Suzuki
 ___
 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] JavaScriptCore cross context object sharing

2015-06-29 Thread Geoffrey Garen
 The documentation for JSContextGroupCreate states that Contexts in the same 
 group may share and exchange JavaScript objects.”  How is this done?

Your C code can take a JSObjectRef from one context and use JSObjectSetProperty 
on another context’s global object in order to make the JSObjectRef accessible.

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


Re: [webkit-dev] JavaScriptCore: Garbage Collector Issue

2015-05-27 Thread Geoffrey Garen
Hi Max.

The best way to get help with a potential bug in JavaScriptCore is to post 
example code that reproduces the bug to bugs.webkit.org.

 I wrote a XCTest in Xcode which performs multiple calls of the JavaScript 
 library (with loops) but it always stops or freezes after the 292nd call.

Can you post a backtrace of all threads in the frozen state? You can get a 
backtrace from the debugger, or the sample command line tool, or the 
Instruments Time Profiler.

 I guess that the JavaScriptCore context (or virtual machine) are not 
 deinitialized after the method call was successful.

I don’t know what you mean by this. I don’t think this is a thing.

 I even tried a manual deinitialize but it still freezes.

Ditto.

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


Re: [webkit-dev] virtual and override

2015-02-20 Thread Geoffrey Garen
Bokay.

Geoff

 On Feb 20, 2015, at 4:11 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 We have traditionally marked virtual overrides with the 'virtual' keyword for 
 documentation purposes. Nowadays we also have the compiler checked 
 'override'. Using both at the same time seems redundant.
 
 Should we change the coding style so that exactly one of the 'virtual' and 
 'override' must be present for all virtual functions?
 
 
antti
 
 
 
 ___
 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] Let's get bmalloc working on Linux (and delete TCMalloc)

2015-02-13 Thread Geoffrey Garen
 To help to go ahead, I upload a patch to enable bmalloc on EFL port as well 
 as to remove TCMaclloc in CMake.

Thanks!

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


Re: [webkit-dev] Unused parameter warnings / errors / warning fixes

2015-01-26 Thread Geoffrey Garen
 Are there reasons any or all of these shouldn't be written as macros?

Yes: Macros are terrible.

Darin mentioned to me in person a way to resolve the problems I listed. I’ll 
follow up with a patch soon.

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


Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

2015-01-08 Thread Geoffrey Garen
From https://bugs.webkit.org/show_bug.cgi?id=132629: 
https://bugs.webkit.org/show_bug.cgi?id=132629:

MallocBench result vs TCMalloc:

geometric mean speedup: 2.11x faster
biggest speedup (list_allocate): 4.09x faster
Results from perf bots:

OSMemoryTesting/Snap2FinishedLoadingPost:Allocations:Total: 0% (no regression)

PLT: 5%

DOM/GetElement: 42.84%
jslib-attr-jquery: 18.1%
dromaeo-object-string: 13.3%
dom-modify: 12.3%
cssquery-jquery: 5%
cssquery-prototype: 4.8%
cssquery-dojo: 3.8%
dromaeo-object-array: 3.4%
jslib-style-jquery: 3.2%
DYEB: 2.4%
Parser/HTML5-8266-FullRender: 4%
Parser/HTML5-8266-ParseOnly: 5.6%
css-parser-yui: 10.2%
Parser/html-parser: 6.5%
Parser/textarea-parsing: 11.22%
Layout/floats_100_100: 7.22%
Layout/floats_100_100_nested: 9.32%
Layout/floats_20_100: 11.42%
Layout/floats_20_100_nested: 13.86%
Layout/layers_overlap_2d: 6.69%
Layout/auto-grid-lots-of-data: 4.3%
Layout/chapter-reflow-once-random: 3.8%
Layout/fixed-grid-lots-of-data: 5.92%
Interactive/window-resize: 2%
Animation/balls:FrameRate: 4%
DOM/CloneNodes: 13.93%
DOM/DOMDivWalk: 10.7%
DOM/GetElement: 42.84%
DOM/ModifyAttribute: 8.7%
 On Jan 7, 2015, at 4:51 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:
 
 By the way, do you have any number how much is bmalloc faster than TCMalloc ?
 
 If you have it, could you let us know ?
 
 Gyuyoung
 
 On Wednesday, January 7, 2015, Gyuyoung Kim gyuyoung@webkit.org 
 mailto:gyuyoung@webkit.org wrote:
 Hello Geoff,
 
 EFL port has used TCMalloc. To use bmalloc on EFL port, I file a new bug 
 140162 for now.
 When patch is ready, I will upload it to the bug.
 
 Thanks,
 Gyuyoung
 
 On Wednesday, January 7, 2015, Geoffrey Garen gga...@apple.com 
 javascript:_e(%7B%7D,'cvml','gga...@apple.com'); wrote:
 Hi folks.
 
 We’ve been using bmalloc on Mac and iOS for some time now, and it is fast and 
 stable.
 
 Is there a Linux maintainer who would like to take on enabling bmalloc on 
 Linux? The implementation is Unix-y, so it should “just work”. I can advise 
 on this project, but I don’t have a Linux build  test environment.
 
 I plan to remove TCMalloc soon.
 
 Regards,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org 
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 -- 
 Sent from Gyuyoung Iphone
 
 
 -- 
 Sent from Gyuyoung Iphone

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


[webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

2015-01-06 Thread Geoffrey Garen
Hi folks.

We’ve been using bmalloc on Mac and iOS for some time now, and it is fast and 
stable.

Is there a Linux maintainer who would like to take on enabling bmalloc on 
Linux? The implementation is Unix-y, so it should “just work”. I can advise on 
this project, but I don’t have a Linux build  test environment.

I plan to remove TCMalloc soon.

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


Re: [webkit-dev] If you like writing memory smashers, you'll love this

2014-12-16 Thread Geoffrey Garen
 As of r177317, FastMalloc can be disabled at runtime. This means that you 
 can use system memory analysis tools like GuardMalloc, MallocScribble, 
 Instruments allocation tracking, leaks, and heap to debug memory issues in 
 WebKit nightly builds, spade builds, and release builds.
 
 Is this in reference to bmalloc?

Yes.

 Instruments allocation tracking, leaks, and heap were supported with 
 TCMalloc-based FastMalloc for quite some time.

I think you’re remembering that TCMalloc supported malloc zone introspection? 
Yes, it did — and bmalloc doesn’t.

But zone introspection isn’t enough to get malloc/free backtraces, which is 
what you need in order to to do leaks analysis and allocation tracking. (And, 
of course, TCMalloc didn’t support scribbling, guard edges, guard malloc, and 
so on.)

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


Re: [webkit-dev] If you like writing memory smashers, you'll love this

2014-12-16 Thread Geoffrey Garen
 But zone introspection isn’t enough to get malloc/free backtraces, which is 
 what you need in order to to do leaks analysis and allocation tracking. 
 (And, of course, TCMalloc didn’t support scribbling, guard edges, guard 
 malloc, and so on.)
 
 http://trac.webkit.org/changeset/153767 
 http://trac.webkit.org/changeset/153767. It’s somewhat academic though 
 since bmalloc is what is in use on tip of tree.

Holy bananas — I totally missed that!

Yeah, the only features new to bmalloc are the debugging flags, then.

 Do we intend to move the remaining ports over to bmalloc so we can remove 
 TCMalloc from the tree?

Yes.

There’s some work to adopt the right APIs for fast access to thread-specific 
data, and virtual memory allocation.

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


Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)

2014-12-15 Thread Geoffrey Garen
Can you attach the Instruments trace leading up to the crash, and/or a reduced 
copy of the app that can reproduce the crash, to bugzilla?

Thanks,
Geoff

 On Dec 11, 2014, at 7:34 PM, Ian Ragsdale ian.ragsd...@gmail.com wrote:
 
 Actually, looking again, I was running the profile on the device, not the 
 simulator as I had meant to.
 
 One other thing I meant to mention is that I keep three instances of the 
 UIWebView loaded, and I trigger it by paging between them quickly, so perhaps 
 it's an issue with multiple instances? There is always one on screen, and 
 paging from one to the next allocates a new one while an old one is 
 discarded. They all appear to share the same WebThread  JavaScript threads, 
 so I could see that being problematic.
 
 - Ian
 
 On Dec 11, 2014, at 9:25 PM, Ian Ragsdale ian.ragsd...@gmail.com wrote:
 
 Hi Geoff, thanks for the quick response!
 
 I don't believe I'm making any use of SPI, aside from whatever underlying 
 use there is in UIWebView - I'm pretty sure that's not exposed to normal iOS 
 apps (at least not that I'm aware of).
 
 As predicted, setting JSC_slowPathAllocsBetweenGCs does appear to make it 
 easier to trigger the crash. I did that and then did an Instruments sample 
 using the iOS simulator, and got the crash to happen pretty quickly. 
 However, I'm not really sure what to look for, since I'm a newbie to WebKit 
 internals. Any suggestions for what to look for in the call tree?
 
 Thanks again,
 Ian
 
 On Dec 11, 2014, at 8:11 PM, Geoffrey Garen gga...@apple.com wrote:
 
 Hi Ian.
 
 From looking at the source, it tries to drop all locks from the current 
 javascript VM before calling the delegate, and when it does that it 
 asserts if the VM is busy garbage collecting.
 
 That’s right.
 
 I'm guessing there needs to be some sort of guard there to make sure the 
 VM isn't doing GC before dropping the locks?
 
 In JavaScriptCore, garbage collection is an atomic operation that must run 
 to completion before the next allocation.
 
 The reason this is an assertion — and can’t be a guard — is that, if we 
 called out to a delegate in the middle of garbage collection, we would 
 definitely corrupt the heap. So, there’s nothing you can guard against: the 
 game is already lost.
 
 The bug here happened earlier: Somehow, the collector was left thinking 
 that it was in the busy state, even though — as we can see from the 
 backtrace — it wasn’t actually doing anything.
 
 I'm pretty positive I'm not calling into the UIWebView from any thread 
 other than the main thread, and I don't think I have any control over the 
 WebThread or the GC threads, so I'm not sure if there's anything I can do, 
 but I do have a fairly reliable repro, so if there's something it makes 
 sense for me to test, I can do so.
 
 Does you app make any use of WebKit SPI? If it does, the SPI might not be 
 thread-safe even if called from the main thread, and so you might be 
 corrupting the heap.
 
 One technique that might make this bug more reproducible is to set the 
 environment variable JSC_slowPathAllocsBetweenGCs to a low number (as low 
 as possible without making your app unusable) — that will trigger 
 collection more frequently.
 
 Another thing you can try is to record an Instruments time profile of the 
 app as you go through the steps to make the app crash. That will give us an 
 overview of what the app was doing leading up to the crash, whether it used 
 UIWebView from a secondary thread or invoked SPI, and so on.
 
 Geoff
 
 

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


[webkit-dev] If you like writing memory smashers, you'll love this

2014-12-15 Thread Geoffrey Garen
As of r177317, FastMalloc can be disabled at runtime. This means that you can 
use system memory analysis tools like GuardMalloc, MallocScribble, Instruments 
allocation tracking, leaks, and heap to debug memory issues in WebKit nightly 
builds, spade builds, and release builds.

FastMalloc automatically disables itself in the presence of environment 
variables that enable Malloc debugging APIs. For giggles, you can also manually 
disable FastMalloc by setting the “Malloc” environment variable to “1”.

Happy memory smashing.

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


Re: [webkit-dev] DropAllLocks assertion on iOS (threading issue?)

2014-12-11 Thread Geoffrey Garen
Hi Ian.

 From looking at the source, it tries to drop all locks from the current 
 javascript VM before calling the delegate, and when it does that it asserts 
 if the VM is busy garbage collecting.

That’s right.

 I'm guessing there needs to be some sort of guard there to make sure the VM 
 isn't doing GC before dropping the locks?

In JavaScriptCore, garbage collection is an atomic operation that must run to 
completion before the next allocation.

The reason this is an assertion — and can’t be a guard — is that, if we called 
out to a delegate in the middle of garbage collection, we would definitely 
corrupt the heap. So, there’s nothing you can guard against: the game is 
already lost.

The bug here happened earlier: Somehow, the collector was left thinking that it 
was in the busy state, even though — as we can see from the backtrace — it 
wasn’t actually doing anything.

 I'm pretty positive I'm not calling into the UIWebView from any thread other 
 than the main thread, and I don't think I have any control over the WebThread 
 or the GC threads, so I'm not sure if there's anything I can do, but I do 
 have a fairly reliable repro, so if there's something it makes sense for me 
 to test, I can do so.

Does you app make any use of WebKit SPI? If it does, the SPI might not be 
thread-safe even if called from the main thread, and so you might be corrupting 
the heap.

One technique that might make this bug more reproducible is to set the 
environment variable JSC_slowPathAllocsBetweenGCs to a low number (as low as 
possible without making your app unusable) — that will trigger collection more 
frequently.

Another thing you can try is to record an Instruments time profile of the app 
as you go through the steps to make the app crash. That will give us an 
overview of what the app was doing leading up to the crash, whether it used 
UIWebView from a secondary thread or invoked SPI, and so on.

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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Geoffrey Garen
Yes, good point. I should have been more specific. I believe this math might 
overflow and then truncate:

templatetypename T, unsigned inlineCapacity, typename OverflowHandler
bool VectorT, inlineCapacity, OverflowHandler::tryExpandCapacity(unsigned 
newMinCapacity)
{
return tryReserveCapacity(std::max(newMinCapacity, std::max(16u, 
static_castunsigned(capacity() + capacity() / 4 + 1;
}

Geoff

 On Nov 19, 2014, at 2:04 PM, Chris Dumez cdu...@apple.com wrote:
 
 Hi,
 
 I believe the Vector class is already checking for overflows. I looked 
 quickly and it seems that when trying to allocate / reallocate the Vector 
 buffer, we will call CRASH() if:
 (newCapacity  std::numeric_limitsunsigned::max() / sizeof(T))
 
 Kr, 
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 
 
 
 On Nov 19, 2014, at 1:57 PM, Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 
 I don’t haver a specific opinion on size_t vs unsigned, but I have a related 
 point:
 
 If Vector uses unsigned, then it must RELEASE_ASSERT that it does not 
 overflow unsigned when growing. 
 
 Even if most normal content allocates  4GB, exploit content surely will try 
 to allocate  4GB.
 
 Chris, maybe you can make this change in trunk, since trunk uses unsigned?
 
 Geoff
 
 On Nov 19, 2014, at 1:50 PM, Alexey Proskuryakov a...@webkit.org 
 mailto:a...@webkit.org wrote:
 
 
 That makes good sense for internal implementation, do you think that class 
 API should also use a custom type, or should it use size_t?
 
 With Vector though, I don't know how we would differentiate code paths that 
 need large allocations from ones that don't. Nearly anything that is 
 exposed as a JS API or deals with external world can hit sizes over 4Gb. 
 That's not out of reach in most scenarios, not even for resources loaded 
 from network.
 
 - Alexey
 
 
 19 нояб. 2014 г., в 13:19, Filip Pizlo fpi...@apple.com 
 mailto:fpi...@apple.com написал(а):
 
 ArrayBuffers are very special because they are part of ECMAScript.
 
 We use unsigned for the length, because once upon a time, that would have 
 been the right type; these days the right type would be a 53-bit integer.  
 So, size_t would be wrong.  I believe that ArrayBuffers should be changed 
 to use a very special size type; probably it wouldn't even be a primitive 
 type but a class that carefully checked that you never overflowed 53 bits.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:54 PM, Alexey Proskuryakov a...@webkit.org 
 mailto:a...@webkit.org wrote:
 
 
 This is not exactly about Vector, but if one uses 
 FileReader.prototype.readAsArrayBuffer() on a large file, I think that it 
 overflows ArrayBuffer. WebKit actually crashes when uploading 
 multi-gigabyte files to YouTube, Google Drive and other similar services, 
 although I haven't checked whether it's because of ArrayBuffers, or 
 because of a use of int/unsigned in another code path.
 
 I think that we should use size_t everywhere except for perhaps a few key 
 places where memory impact is critical (and of course we need explicit 
 checks when casting down to an unsigned). Or perhaps the rule can be even 
 simpler, and unsigned may never be used for indices and sizes, period.
 
 - Alexey
 
 
 19 нояб. 2014 г., в 12:32, Filip Pizlo fpi...@apple.com 
 mailto:fpi...@apple.com написал(а):
 
 Whatever we do, the clients of Vector should be consistent about what 
 type they use.  I'm actually fine with Vector internally using unsigned 
 even if the API uses size_t, but right now we have lots of code that 
 uses a mix of size_t and unsigned when indexing into Vectors.  That's 
 confusing.
 
 If I picked one type to use for all Vector indices, it would be unsigned 
 rather than size_t.  Vector being limited to unsigned doesn't imply 4GB 
 unless you do Vectorchar.  Usually we have Vectors of pointer-width 
 things, which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)).  
 Even in a world where we had more than 32GB of memory to use within a 
 single web process, I would hope that we wouldn't use it all on a single 
 Vector and that if we did, we would treat that one specially for a bunch 
 of other sensible reasons (among them being that allocating a contiguous 
 slab of virtual memory of that size is rather taxing).  So, size_t would 
 buy us almost nothing since if we had a vector grow large enough to need 
 it, we would be having a bad time already.
 
 I wonder: are there cases that anyone remembers where we have tried to 
 use Vector to store more than UINT_MAX things?  Another interesting 
 question is: What's the largest number of things that we store into any 
 Vector?  We could use such a metric to project how big Vectors might get 
 in the future.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:20 PM, Chris Dumez cdu...@apple.com 
 mailto:cdu...@apple.com wrote:
 
 Hi all,
 
 I recently started updating the WTF::Vector API to use unsigned types 
 instead of size_t [1][2], because:
 - WTF::Vector is already using unsigned type for size

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Geoffrey Garen
 I wonder what the downsides are to this approach.  Footprint of Vector?

It looks like the original change was motivated by shrinking Vector:

https://bugs.webkit.org/show_bug.cgi?id=97268 
https://bugs.webkit.org/show_bug.cgi?id=97268

Sadly, it didn’t include any data on the observed benefit :(.

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


Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-19 Thread Geoffrey Garen
I don’t haver a specific opinion on size_t vs unsigned, but I have a related 
point:

If Vector uses unsigned, then it must RELEASE_ASSERT that it does not overflow 
unsigned when growing. 

Even if most normal content allocates  4GB, exploit content surely will try to 
allocate  4GB.

Chris, maybe you can make this change in trunk, since trunk uses unsigned?

Geoff

 On Nov 19, 2014, at 1:50 PM, Alexey Proskuryakov a...@webkit.org wrote:
 
 
 That makes good sense for internal implementation, do you think that class 
 API should also use a custom type, or should it use size_t?
 
 With Vector though, I don't know how we would differentiate code paths that 
 need large allocations from ones that don't. Nearly anything that is exposed 
 as a JS API or deals with external world can hit sizes over 4Gb. That's not 
 out of reach in most scenarios, not even for resources loaded from network.
 
 - Alexey
 
 
 19 нояб. 2014 г., в 13:19, Filip Pizlo fpi...@apple.com 
 mailto:fpi...@apple.com написал(а):
 
 ArrayBuffers are very special because they are part of ECMAScript.
 
 We use unsigned for the length, because once upon a time, that would have 
 been the right type; these days the right type would be a 53-bit integer.  
 So, size_t would be wrong.  I believe that ArrayBuffers should be changed to 
 use a very special size type; probably it wouldn't even be a primitive type 
 but a class that carefully checked that you never overflowed 53 bits.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:54 PM, Alexey Proskuryakov a...@webkit.org 
 mailto:a...@webkit.org wrote:
 
 
 This is not exactly about Vector, but if one uses 
 FileReader.prototype.readAsArrayBuffer() on a large file, I think that it 
 overflows ArrayBuffer. WebKit actually crashes when uploading 
 multi-gigabyte files to YouTube, Google Drive and other similar services, 
 although I haven't checked whether it's because of ArrayBuffers, or because 
 of a use of int/unsigned in another code path.
 
 I think that we should use size_t everywhere except for perhaps a few key 
 places where memory impact is critical (and of course we need explicit 
 checks when casting down to an unsigned). Or perhaps the rule can be even 
 simpler, and unsigned may never be used for indices and sizes, period.
 
 - Alexey
 
 
 19 нояб. 2014 г., в 12:32, Filip Pizlo fpi...@apple.com 
 mailto:fpi...@apple.com написал(а):
 
 Whatever we do, the clients of Vector should be consistent about what type 
 they use.  I'm actually fine with Vector internally using unsigned even if 
 the API uses size_t, but right now we have lots of code that uses a mix of 
 size_t and unsigned when indexing into Vectors.  That's confusing.
 
 If I picked one type to use for all Vector indices, it would be unsigned 
 rather than size_t.  Vector being limited to unsigned doesn't imply 4GB 
 unless you do Vectorchar.  Usually we have Vectors of pointer-width 
 things, which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)).  
 Even in a world where we had more than 32GB of memory to use within a 
 single web process, I would hope that we wouldn't use it all on a single 
 Vector and that if we did, we would treat that one specially for a bunch 
 of other sensible reasons (among them being that allocating a contiguous 
 slab of virtual memory of that size is rather taxing).  So, size_t would 
 buy us almost nothing since if we had a vector grow large enough to need 
 it, we would be having a bad time already.
 
 I wonder: are there cases that anyone remembers where we have tried to use 
 Vector to store more than UINT_MAX things?  Another interesting question 
 is: What's the largest number of things that we store into any Vector?  We 
 could use such a metric to project how big Vectors might get in the future.
 
 -Filip
 
 
 On Nov 19, 2014, at 12:20 PM, Chris Dumez cdu...@apple.com 
 mailto:cdu...@apple.com wrote:
 
 Hi all,
 
 I recently started updating the WTF::Vector API to use unsigned types 
 instead of size_t [1][2], because:
 - WTF::Vector is already using unsigned type for size/capacity internally 
 to save memory on 64-bit, causing a mismatch between the API and the 
 internal representation [3]
 - Some reviewers have asked me to use unsigned for loop counters 
 iterating over vectors (which looks unsafe as the Vector API, e.g. 
 size(), returns a size_t).
 - I heard from Joseph that this type mismatch is forcing us (and other 
 projects using WTF) to disable some build time warnings
 - The few people I talked to before making that change said we should do 
 it
 
 However, Alexey recently raised concerns about this change. it doesn't 
 strike him as the right direction. 4Gb is not much, and we should have 
 more of WebKit work with the right data types, not less.”.
 I did not initially realize that this change was controversial, but now 
 that it seems it is, I thought I would raise the question on webkit-dev 
 to see what people think about this.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, 

Re: [webkit-dev] Tagged assertions...

2014-11-06 Thread Geoffrey Garen
In debug builds, in addition to a backtrace, don’t assertions already provide a 
text description and a line number?

Perhaps we need a more searchable way to record these fields in our bug 
tracking databases. But it’s not immediately clear to me why adding a third 
field would help.

Geoff

 On Nov 6, 2014, at 11:19 AM, Said Abou-Hallawa sabouhall...@apple.com wrote:
 
 Recently I ran into an issue where I wanted to find if there is a bug filed 
 against a certain assertion. The only way I was able to use is to search for 
 the name of the function which has the assertion.  The function can be 
 overloaded or the function can have more than one assertion.  So I found it 
 difficult to track the assertion I am interested in.  In future if the 
 function gets renamed, it will be even more difficult.
 
 I have a suggestion for this.
 
 A pre-build tool will tag every new assertion after the change is committed.  
 For example in the code I will add the following assertion:
 
   ASSERT(condition);
 
 The pre-build tool will change it to be:
 
   ASSERT_TAG(condition, “abcde”);
 
 where “abcde” is a unique tag in all the source code.  A database should be 
 maintained by the build process to keep track what tags are available to be 
 assigned.
 
 When the assertion fires, the dump may look like the following:
 
   ASSERTION FAILED (tag: abcde) condition
   … rest of the call-stack
 
 In Bugzilla, there should be a field for the assertion tag.  If I want to 
 file an assertion bug, I should be filling this field like the following:
 
   Product:WebKit
   Summary:ASSERTION failed in someFunction
   Assertion tag:  abcde
   Description:
   Attachment:
 
 Later if the assertion fires, from the dump I can know exactly what assertion 
 fired.  And more importantly I can search for it easily.  In the Bugzilla 
 search page, I should see a field for the assertion tag in the simple search 
 page:
 
   Status: All
   Product:WebKit
   Words:
   Assertion tag:  abcde
 
 This search will bring me all the opened bugs in WebKit which has the 
 assertion tag = “abcde” if there is any.
 
   ID  Product CompAssigneeStatus  
 Resolution  Assertion tag   Summary
   12345   WebKit  
 abcde   ASSERTION failed in 
 someFunction
 
 Thanks,
 Said
 
 ___
 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] Tagged assertions...

2014-11-06 Thread Geoffrey Garen
 The function name and the line number may change if the code changes.

How often do these kinds of changes cause problems?

When function names and line numbers do change, doesn’t the message still 
identify the assertion?

Geoff

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


Re: [webkit-dev] Keep ResourceBuffer?

2014-10-23 Thread Geoffrey Garen
I think Brady explained to me — a year ago? — what ResourceBuffer’s goal was. 

Brady, do you remember?

Geoff

 On Oct 23, 2014, at 9:42 AM, Darin Adler da...@apple.com wrote:
 
 Hi folks.
 
 I’ve noticed that we have an unused abstraction in the loader code. 
 ResourceBuffer is a cover for a SharedBuffer, with comments and remnants of 
 an older effort to make it some kind of abstraction. But at the moment it’s 
 just overhead and no abstraction.
 
 Does anyone object to my eliminating ResourceBuffer for now and changing code 
 to use SharedBuffer directly instead?
 
 — 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


Re: [webkit-dev] JavaScriptCore subclass native class created with JSClassCreate in javascript code

2014-10-06 Thread Geoffrey Garen
Did you make sure to indicate, using the C API, that TestClass/parent class was 
the parent class of SubClass?

Geoff

 On Oct 5, 2014, at 4:48 AM, Moritz Moeller mmoel...@mxs.de wrote:
 
 Hi,
 
 thank you for the feedback!
 
 The constructor call now works, but the setProperty call does not seem to get 
 forwarded.
 
 If i do (new SubClass()).someProperty = true; the setProperty method of the 
 TestClass/parent class is not called.
 
 getProperty is called though.
 
 There does not seem to be any Object.defineProperty API on the C level?
 
 Thank you,
 
 Moritz
 
 
 On 03 Oct 2014, at 1:37 , Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 
 …Yet another option is to insert Function.prototype into the TestClass 
 prototype chain.
 
 Geoff
 
 On Oct 2, 2014, at 4:37 PM, Geoffrey Garen gga...@apple.com 
 mailto:gga...@apple.com wrote:
 
 You’ll need to manually copy Function.prototype.apply to the TestClass 
 prototype.
 
 Another option is “Function.prototype.apply.call(TestClass, this, 
 arguments)”.
 
 Geoff
 
 On Oct 2, 2014, at 8:26 AM, Moritz Moeller mmoel...@mxs.de 
 mailto:mmoel...@mxs.de wrote:
 
 Hi,
 
 I’ve created a javascript class in native code (i.e. JSClassCreate, 
 JSObjectMakeConstructor etc.) and want to subclass this class in 
 javascript.
 
 So pretty much:
 
 JSClassDefinition classDef = kJSClassDefinitionEmpty;
 classDef.className = TestClass;
 classDef.getProperty = class_getProperty;
 classDef.setProperty = class_setProperty;
 JSClassRef classRef = JSClassCreate(classDef);
 JSObjectRef constructor = JSObjectMakeConstructor(ctx, gClassRef, 
 class_constructor);
 JSObjectSetProperty(ctx, JSContextGetGlobalObject(ctx), 
 JsString(TestClass), constructor, 0, NULL);
 
 class_constructor does:
 return JSObjectMake(ctx, classRef, NULL);
 
 This works, so I can do
 var test = new TestClass();
 test.field = 1;
 
 and both class_constructor and class_setProperty is called.
 
 Now I’m trying to subclass the TestClass:
 function SubClass()
 {
 TestClass.apply(this, arguments);
 }
 
 here it already got the problem that TestClass - being a constructor - 
 does not have .bind() or .apply().
 
 Does someone know how to get this working?
 
 Thank you very much,
 
 Mo
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 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] JavaScriptCore subclass native class created with JSClassCreate in javascript code

2014-10-02 Thread Geoffrey Garen
You’ll need to manually copy Function.prototype.apply to the TestClass 
prototype.

Another option is “Function.prototype.apply.call(TestClass, this, arguments)”.

Geoff

 On Oct 2, 2014, at 8:26 AM, Moritz Moeller mmoel...@mxs.de wrote:
 
 Hi,
 
 I’ve created a javascript class in native code (i.e. JSClassCreate, 
 JSObjectMakeConstructor etc.) and want to subclass this class in javascript.
 
 So pretty much:
 
 JSClassDefinition classDef = kJSClassDefinitionEmpty;
 classDef.className = TestClass;
 classDef.getProperty = class_getProperty;
 classDef.setProperty = class_setProperty;
 JSClassRef classRef = JSClassCreate(classDef);
 JSObjectRef constructor = JSObjectMakeConstructor(ctx, gClassRef, 
 class_constructor);
 JSObjectSetProperty(ctx, JSContextGetGlobalObject(ctx), 
 JsString(TestClass), constructor, 0, NULL);
 
 class_constructor does:
 return JSObjectMake(ctx, classRef, NULL);
 
 This works, so I can do
 var test = new TestClass();
 test.field = 1;
 
 and both class_constructor and class_setProperty is called.
 
 Now I’m trying to subclass the TestClass:
 function SubClass()
 {
 TestClass.apply(this, arguments);
 }
 
 here it already got the problem that TestClass - being a constructor - does 
 not have .bind() or .apply().
 
 Does someone know how to get this working?
 
 Thank you very much,
 
 Mo
 ___
 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] JavaScriptCore subclass native class created with JSClassCreate in javascript code

2014-10-02 Thread Geoffrey Garen
…Yet another option is to insert Function.prototype into the TestClass 
prototype chain.

Geoff

 On Oct 2, 2014, at 4:37 PM, Geoffrey Garen gga...@apple.com wrote:
 
 You’ll need to manually copy Function.prototype.apply to the TestClass 
 prototype.
 
 Another option is “Function.prototype.apply.call(TestClass, this, arguments)”.
 
 Geoff
 
 On Oct 2, 2014, at 8:26 AM, Moritz Moeller mmoel...@mxs.de 
 mailto:mmoel...@mxs.de wrote:
 
 Hi,
 
 I’ve created a javascript class in native code (i.e. JSClassCreate, 
 JSObjectMakeConstructor etc.) and want to subclass this class in javascript.
 
 So pretty much:
 
 JSClassDefinition classDef = kJSClassDefinitionEmpty;
 classDef.className = TestClass;
 classDef.getProperty = class_getProperty;
 classDef.setProperty = class_setProperty;
 JSClassRef classRef = JSClassCreate(classDef);
 JSObjectRef constructor = JSObjectMakeConstructor(ctx, gClassRef, 
 class_constructor);
 JSObjectSetProperty(ctx, JSContextGetGlobalObject(ctx), 
 JsString(TestClass), constructor, 0, NULL);
 
 class_constructor does:
 return JSObjectMake(ctx, classRef, NULL);
 
 This works, so I can do
 var test = new TestClass();
 test.field = 1;
 
 and both class_constructor and class_setProperty is called.
 
 Now I’m trying to subclass the TestClass:
 function SubClass()
 {
 TestClass.apply(this, arguments);
 }
 
 here it already got the problem that TestClass - being a constructor - does 
 not have .bind() or .apply().
 
 Does someone know how to get this working?
 
 Thank you very much,
 
 Mo
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto: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] WebCore.exp.in

2014-08-21 Thread Geoffrey Garen
To make this list of exported symbols, you should be able to use nm -g -U 
/path/to/framework”.

Geoff

 On Aug 20, 2014, at 6:26 PM, Darin Adler da...@apple.com wrote:
 
 I think it’s a great idea to do this.
 
 But once we are ready to throw the switch I would like to review the 
 difference between what’s going to be exported without the .exp files and 
 what will be exported afterwards to look for problems. We did something like 
 that with JavaScriptCore. If we manage to do this correctly that diff should 
 be pretty small.
 
 — 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


  1   2   3   4   >