Re: [webkit-dev] git-webkit pr now supports --no-ews / --ews flags

[Geoffrey Garen via webkit-dev]

This is great!

As it is said in "Ghost Dog: The Way of the Samurai", it is bad when one thing 
becomes two. Can we pick one name for this feature? Either —no-ews (git-webkit) 
and no-ews (GitHub) or —skip-ews (git-webkit) and skip-ews (GitHub)?

Thanks,
Geoff

> On Jan 26, 2023, at 11:36 AM, Aakash Jain via webkit-dev 
>  wrote:
> 
> Hi Everyone,
> 
> git-webkit pr now supports --no-ews / --ews flags (as of 259115@main). This 
> is similar to --no-ews flag we had in webkit-patch.  You can also manually 
> add skip-ews label on any PR when you don't need EWS to run anymore on it. 
> --no-ews flag will also automatically add the skip-ews label on the 
> corresponding GitHub PR.
> 
> Please feel free to use skip-ews GitHub label or --no-ews flag in git-webkit 
> pr, when you don't need to run EWS for any reason (e.g.: PR failed a critical 
> EWS indicating need for new iteration, and you don't need to run rest of the 
> EWSes on that commit).
> 
> If you notice any issues, please let me know or file bugs (and assign to me).
> 
> 
> Thanks
> Aakash
> ___
> 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] Stop Using Raw Pointers & References in New Code

[Geoffrey Garen via webkit-dev]

Is the idea that a checker failure should block landing a patch, or just that 
it should start a conversation with your patch reviewer about why this case is 
an exception?

Maybe the ’should’ clause in the error message could clarify.

In general, I do think it’s helpful to flag any new raw pointer usage in a 
member variable. But I also agree that it might not be practical to get that 
number to true zero.

Thanks,
Geoff

> On Jan 21, 2023, at 12:12 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Fri, Jan 20 2023 at 06:15:38 PM -0800, Ryosuke Niwa via webkit-dev 
>  wrote:
>> Here´s a PR to make the style checker look for raw pointers & references in 
>> data members: https://github.com/WebKit/WebKit/pull/8907
>> I suggest we land this PR in 5 business days from now on unless someone 
>> objects.
> 
> I'm not sure how this would work as a style check rule since there's always 
> going to be exceptions. E.g. we probably don't want to convert GObject priv 
> pointers to use CheckedRef: that would be silly.
> 
> I think we can follow this rule in most of WebCore and maybe most of WebKit 
> and WTF as well. Probably not going to work for bmalloc. Not sure about JSC.
> 
> Michael
> 
> 
> ___
> 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] Compile times and class-scoped enums

[Geoffrey Garen via webkit-dev]

>> However, this change requires moving class-scoped enums out into the 
>> namespace scope.
> 
> Seems worthwhile. Doesn’t seem to me like it would have far reaching effects.

I agree.

> +using Type = DOMAudioSessionType;

Did you do this to make the patch smaller, or do you prefer this style?

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

[webkit-dev] Ben Nham is now a WebKit Reviewer

[Geoffrey Garen via webkit-dev]

Hi folks,

I’m happy to announce that Ben Nham is now a WebKit reviewer. 

Ben is an expert in many Apple technologies, and in Performance and WebPush in 
particular. Please feel free to reach out to Ben for reviews.

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

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

[Geoffrey Garen via webkit-dev]

Thanks for gathering this data!

>> What are some notable cases of recent regressions that have landed because 
>> of non-use of commit queue and caused serious problems?
> 
> Some recent examples of regressions that would have been prevented by 
> mandatory commit/merge-queue as proposed:
> 
> https://commits.webkit.org/250940@main 
>  (PR did use Merge-Queue, but we’re 
> missing the feature that would have caught the problem)

What feature specifically?

> https://commits.webkit.org/250343@main 
>  (Commit did use Commit-Queue, but 
> skipped layout tests because of a previous iteration passed EWS)

Are you also proposing that merge-queue should re-run layout tests 
unconditionally? Do we know how long that takes on average? Do we have the 
hardware to support that?

> https://commits.webkit.org/250791@main 
>  (Should have failed EWS, but flakey 
> tests had different names, cross referencing trunk results would have made 
> that obvious)

How would merge-queue cross reference with trunk results or otherwise resolve 
this confusion?

> https://commits.webkit.org/248624@main 
>  (Landed manually, broke the build)

Seems like this would have been avoided by Merge-Queue alone. That’s nice.

For the other three cases, whether the proposal as-is would have resolved them 
or not seems muddy. Might need revision.

Thanks,
Geoff

>> Do you have any data on how frequent such regressions are, compared to the 
>> base rate of regressions that have landed despite use of commit queue?
> 
> Commit and Merge queue have basically prevented us from breaking the Mac 
> build, the only example of a broken Mac build I can find come from by-passing 
> Commit and Merge Queue. Layout test breakages are quite a bit more difficult 
> to reason about because breakages tend to not just be platform specific, but 
> configuration specific as well.
> 
>> 
>> Do you have any data on how frequently regressions are resolved by patches 
>> that land outside commit queue?
> 
> In the last week, we had 200 commits. 50 of those were made through the 
> Unsafe-Merge-Queue. Break down is here:
> 
> 15 were feature work that should have gone through Merge Queue
> 12 were test gardening
> 9 were build or test fixes
> 3 were 3rd party imports
> 3 were reverts
> 3 were tooling changes
> 2 were buildbot changes
> 2 were contributors.json changes
> 1 was a documentation change
> 
> My proposal would have sent the feature work, gardening work, imports, 
> tooling change and documentation change to Merge-Queue rather than 
> Unsafe-Merge-Queue. The build and test fixes would have needed modification 
> to their commit messages, but were the kind of changes I would want landed 
> via Unsafe-Merge-Queue.
> 
>> 
>>> and reduce demands of post-commit test gardening.
>> 
>> Is this goal distinct from preventing regressions from landing? If so, how?
> 
> I suppose I should have said:
> "The goal is to increase the stability of the build, speed up EWS and reduce 
> demands of post-commit test gardening by preventing regressions from 
> landing”, since build instability, slow EWS and post-commit test gardening 
> are all consequences of regressions landing.
> 
>> 
 What problem are you trying to solve, and with what level of urgency?
>>> 
>>> Urgency is not high. I started this with the expectation it would be a 
>>> somewhat long and contentious discussion. The motivating change is that the 
>>> GitHub transition makes this proposal possible, from a technical 
>>> perspective, in a way it is not while the project is still backed by 
>>> Subversion.
>> 
>> I don’t understand the premise here. There are lots of ways to enforce 
>> commit policy on a Subversion repository.
> 
> Kind of. The problem here is that we want to provide enough escape hatches so 
> that any committer can quickly repair a broken build, so we have to check not 
> just the committer, but the commit itself. This is more analogous to ensuring 
> that commit has “Reviewed by” in it’s commit message (something that 
> Subversion does not enforce in our repository, despite it being policy) than 
> it is to ensuring that the committer has certain privileges. We’ve always 
> implemented these kind of checks in buildbot, not the Subversion server, and 
> it’s much easier to implement complicated logic that takes into consideration 
> the content of the commit in buildbot than it is Subversion hooks.
> 
>> On the meta level, while we are still dealing with serious regressions in 
>> our workflow caused by git and GitHub, I recommend that we do not push 
>> forward with more unrelated sweeping changes to the project and its 
>> workflow. Just like in software development, where we need to fix 
>> regressions before we can move forward with major feature work, so too in 
>> tooling we need to do the same. Otherwise we just pile chaos 

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Geoffrey Garen via webkit-dev]

> As such, I also think that the non-unified EWS being green should not be a 
> blocker to landing a patch. But I think having it there for information will 
> help the situation. At minimum, even if every engineer simply ignores the 
> non-unified EWS, it also makes it easier for someone trying to fix a trim 
> missing include build issue to scan through PRs to look for this EWS failure 
> in order to narrow down on which patches (and therefore possible includes) to 
> focus on.

Is this the proposal on the table — to have an EWS bot, but also not block 
patches on it? 

That’s surprising to me, and not how EWS bots usually work. If we just want an 
optional record of where a particular build configuration started failing, 
Isn’t that just… a not-EWS bot?

Thanks,
Geoff

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

Re: [webkit-dev] Proposal: Mandatory Commit and Merge Queue

[Geoffrey Garen via webkit-dev]

>> What is the goal of this proposal?
> 
> The goal is to increase the stability of the build

Is this goal distinct from preventing regressions from landing? If so, how?

> , speed up EWS by preventing regressions from landing

What are some notable cases of recent regressions that have landed because of 
non-use of commit queue and caused serious problems?

Do you have any data on how frequent such regressions are, compared to the base 
rate of regressions that have landed despite use of commit queue?

Do you have any data on how frequently regressions are resolved by patches that 
land outside commit queue?

> and reduce demands of post-commit test gardening.

Is this goal distinct from preventing regressions from landing? If so, how?

>> What problem are you trying to solve, and with what level of urgency?
> 
> Urgency is not high. I started this with the expectation it would be a 
> somewhat long and contentious discussion. The motivating change is that the 
> GitHub transition makes this proposal possible, from a technical perspective, 
> in a way it is not while the project is still backed by Subversion.

I don’t understand the premise here. There are lots of ways to enforce commit 
policy on a Subversion repository.

On the meta level, while we are still dealing with serious regressions in our 
workflow caused by git and GitHub, I recommend that we do not push forward with 
more unrelated sweeping changes to the project and its workflow. Just like in 
software development, where we need to fix regressions before we can move 
forward with major feature work, so too in tooling we need to do the same. 
Otherwise we just pile chaos on top of chaos, and there is no way to know if 
things are improving or getting worse, and no way to hold ourselves accountable 
for improvement. 

Thanks,
Geoff

> 
> Jonathan
> 
>> 
>> Thanks,
>> Geoff
>> 
>> 
>>> On Jun 2, 2022, at 2:35 PM, Jonathan Bedard via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> As we move to GitHub, I would like to propose we strengthen our protections 
>>> on `main` by making MergeQueue and CommitQueue mandatory. This would mean 
>>> that with a few exceptions, all changes would need to be built and run 
>>> layout tests before they are landed. To spell out what the exceptions I had 
>>> in mind are:
>>> 
>>> - Revert commits, identified by a commit message that starts with 
>>> “Unreviewed, revering…” would be exempt
>>> - Changes which only modify files that do not effect building or testing 
>>> WebKit would be exempt. These files specifically are:
>>>  .github/
>>>  JSTests/
>>>  ManualTests/
>>>  metadata/
>>>  PerformanceTests/
>>>  Tools/
>>>  CISuport/
>>>  EWSTools/
>>>  WebKitBot
>>> Websites/
>>> - Emergency build and infrastructure fixes, identified by a commit message 
>>> that starts with “Emergency build fix” or “Emergency infrastructure fix” 
>>> would be exempt
>>> - A reviewer who is not the commit author can overwrite this protection by 
>>> adding `unsafe-merge-queue` instead of the commit author
>>> - Changes which passed an EWS layout test queue within the last 7 days 
>>> would skip the layout test check
>>> 
>>> These exceptions are designed to provide contributors for a way to by-pass 
>>> potentially slow checks if extraordinary situations, or in ones where CI 
>>> has already validated the change. I think we should keep the ability for 
>>> any committer to deploy an emergency fix, because our project has many 
>>> contributors in different timezones and with different holiday schedules.
>>> 
>>> We know that this policy change would potentially slow down development, so 
>>> I think these 3 improvements block making MergeQueue and CommitQueue 
>>> mandatory:
>>> 
>>> - run-webkit-tests consulting results.webkit.org 
>>>  to avoid retrying known flakey or failing tests
>>> - Another MergeQueue bot
>>> - Xcode workspace builds to speed up incremental builds
>>> 
>>> Jonathan Bedard
>>> WebKit Continuous Integration
>>> 
>>> ___
>>> 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: Mandatory Commit and Merge Queue

[Geoffrey Garen via webkit-dev]

> As we move to GitHub, I would like to propose we strengthen our protections 
> on `main` by making MergeQueue and CommitQueue mandatory. 


What is the goal of this proposal?

What problem are you trying to solve, and with what level of urgency?

Thanks,
Geoff


> On Jun 2, 2022, at 2:35 PM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> As we move to GitHub, I would like to propose we strengthen our protections 
> on `main` by making MergeQueue and CommitQueue mandatory. This would mean 
> that with a few exceptions, all changes would need to be built and run layout 
> tests before they are landed. To spell out what the exceptions I had in mind 
> are:
> 
> - Revert commits, identified by a commit message that starts with 
> “Unreviewed, revering…” would be exempt
> - Changes which only modify files that do not effect building or testing 
> WebKit would be exempt. These files specifically are:
>  .github/
>  JSTests/
>  ManualTests/
>  metadata/
>  PerformanceTests/
>  Tools/
>CISuport/
>EWSTools/
>WebKitBot
> Websites/
> - Emergency build and infrastructure fixes, identified by a commit message 
> that starts with “Emergency build fix” or “Emergency infrastructure fix” 
> would be exempt
> - A reviewer who is not the commit author can overwrite this protection by 
> adding `unsafe-merge-queue` instead of the commit author
> - Changes which passed an EWS layout test queue within the last 7 days would 
> skip the layout test check
> 
> These exceptions are designed to provide contributors for a way to by-pass 
> potentially slow checks if extraordinary situations, or in ones where CI has 
> already validated the change. I think we should keep the ability for any 
> committer to deploy an emergency fix, because our project has many 
> contributors in different timezones and with different holiday schedules.
> 
> We know that this policy change would potentially slow down development, so I 
> think these 3 improvements block making MergeQueue and CommitQueue mandatory:
> 
> - run-webkit-tests consulting results.webkit.org  
> to avoid retrying known flakey or failing tests
> - Another MergeQueue bot
> - Xcode workspace builds to speed up incremental builds
> 
> Jonathan Bedard
> WebKit Continuous Integration
> 
> ___
> 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: Immediate Deprecation of ChangeLogs

[Geoffrey Garen via webkit-dev]

Do I undertand correctly that the proposal here is

(a) Immediately Deprecate ChangeLogs

(b) Immediately end support for posting patches from Subversion 
checkouts?

If so, do you know how many regular WebKit contributors still post patches from 
Subversion checkouts, and, if that number is not zero, what their schedule is 
for migrating to git, and whether they need anything from our tools engineers 
to make that migration smooth?

Seems… problematically forward-looking… to propose immediate migration without 
that data.

Thanks,
Geoff

> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> A few weeks ago, I started a discussion about deprecating ChangeLogs. In that 
> time, we’ve had more folks using the pull-request workflow and more folks 
> using newer versions of `git` which break automatic ChangeLog rebasing. I 
> propose that on Monday, May 16th, we implement the following policy changes 
> for the WebKit project:
> 
> - Commits no longer require ChangeLogs, they instead require commit messages
> - Commit messages are in the format of `prepare-ChangeLog --no-write`
> 
> Pull-request workflows based on `git-webkit` already support this workflow 
> well, and `git-webkit setup` creates a `prepare-commit-msg` hook that will 
> appropriately format commit messages. In addition, `git format-patch` allows 
> us to create a patch which contains a commit message. This means that 
> contributors still using patch workflows from a git or git-svn checkout will 
> be able to upload compliant patches to bugzilla.
> 
> This will, however, break contributors using pure-Subversion checkouts. This 
> is something that’s going to be happening in the very near future as we 
> deprecate Subversion entirely, so I think this is an acceptable cost in 
> exchange for fully supporting native git workflows.
> 
> The last thing I’d like to note is that a full git-native commit message 
> policy now is something we can modify in the future if we find that reviewing 
> commit messages with “Quote reply” comments is not sufficient, but resolving 
> project disagreements on how or if to address deficiencies in GitHub commit 
> message review don’t seem to be headed towards a resolution quickly.
> 
> Jonathan
> WebKit Continuous Integration
> 
> ___
> 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] ChangeLog Deprecation Plans

[Geoffrey Garen via webkit-dev]

>> Commit message is tied to a commit, so editing commit without breaking 
>> commit-message is hard (how to revert one change from one commit without 
>> rewriting commit message? It requires some git hack). Separate independent 
>> COMMIT_MESSAGE file can solve this problem and makes local development easy.
> 
> Developers who are used to git -- which nowadays is pretty much everyone 
> except WebKit devs -- are also used to rewriting commit messages.

I think it’s important for WebKit's git transition to take consideration of 
WebKit developers and WebKit workflows. I hope we can agree on this premise as 
we discuss various options for commit messages.

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

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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

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

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

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

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

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

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

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

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

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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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'?

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

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

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

[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

[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

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

[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

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

[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