Re: [webkit-dev] Initializing member variables

[Yusuke Suzuki via webkit-dev]

I prefer { } style.
It can catch implicit narrowing bugs, which does not work with = style.

Best regards,
- Yusuke

> On Sep 19, 2024, at 4:13 PM, Jean-Yves Avenard via webkit-dev 
>  wrote:
> 
> 
> 
>> On 20 Sep 2024, at 7:55 AM, Ryosuke Niwa via webkit-dev 
>>  wrote:
>> 
>> 
>> Should we do:
>> 
>> struct Foo {
>> int bar = 0;
>> }
>> 
>> Or
>> 
>> struct Foo {
>> int bar { 0 };
>> }
>> 
>> We do both at the moment.
>> 
>> - R. Niwa
> 
> I think `int bar = 0` reads better.
> 
> I only ever see (and use) { } and I thought that was the proper coding style.
> 
> I’m surprised it’s not in our guidelines. 
> 
> Jean-Yves
> ___
> 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] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Yusuke Suzuki via webkit-dev]

Hello WebKittens!

Right now, MSVC support is putting significant burden on JavaScriptCore. It 
lacks many features for JSC development,
as a result, we have so many workarounds for MSVC in JavaScriptCore (For 
example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot 
compile it reasonably).

I talked with JSC team and Don at Sony, and now I would like to propose 
dropping MSVC support on Windows port and using clang-cl exclusively on Windows.

There are many motivating factors for this change.

1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there 
is zero test coverage on MSVC build right now.
2. On the other hand, EWS is using MSVC for build test. This discrepancy is 
making maintenance of Windows ports harder and harder.
3. MSVC has various compilation issues which makes JSC lesser quality. Lack of 
`__builtin_frame_address` support makes JSC bloating JIT code much. 
CheckedArith has bunch of special code due to lack of overflow-detecting 
`__builtin_add_overflow` like operations, and so on.  (but TBH, given there is 
zero coverage, we even don't know whether it is working right now!)
4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are 
using clang-cl, not MSVC.

Not only solving existing issues, using clang-cl opens significant code / 
implementation quality improvements opportunities for Windows.

1. MSVC does not support various C++20 features, so it is putting our C++20 
adoption much behind (For example, we cannot use  concept). By using clang-cl, 
we can start much newer set of C++20 features, improving code quality, static 
checks etc.
2. This paves a way to make Windows JSC implementation super solid. clang-cl 
offers sysv-abi feature for function attributes. This allows using Linux / 
macOS amd64 ABI on certain annotated functions. This basically means that we 
potentially unify our interpreter and JIT implementations completely in Linux / 
macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super 
solid, plus, it paves a way to fully enable all JIT tiers on Windows including 
FTL).

We already discussed with Don and we agreed on this.
And now I would like to formally propose MSVC deprecation towards more cleaner 
and solid Windows port.

Best regards,
-Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Replacing Cairo in WebKit with Skia

[Yusuke Suzuki via webkit-dev]

Nice, this sounds really good.
Cairo performance was one of the limiting factors in WebKitGTK, and adopting 
some libraries which can use GPU is great improvement.
One of questions is, should we rename WinCairo to something different? (Like, 
Win, or WinSkia).

-Yusuke

> On Feb 2, 2024, at 6:49 AM, Carlos Garcia Campos via webkit-dev 
>  wrote:
> 
> Hi WebKittens,
> 
> At Igalia we have spent some time exploring different options to
> replace the Cairo 2D rendering library in the GTK and WPE ports (we
> even tried rolling our own library). Recently we decided to try Skia
> and we have successfully integrated it in the WPE port. Right now we
> can compile WebKit with Skia linked statically, as part of the CMake
> build, and run a number benchmarks. This has allowed us to compare the
> Skia GPU and CPU renderers with the existing Cairo one in different
> devices.
> 
> The results are very promising: benchmarks are faster than Cairo's CPU
> rendering, specially with Skia's GPU renderer. The improvement varies
> for each device, but in any case it is already clear that the change is
> a net positive on every configuration we have tested. Additionally, the
> integration in the build system is well isolated: importing Skia under
> Source/ThirdParty there is no need for any additional dependencies,
> patching Skia has not been needed, and the changes in WebKit are
> limited to code from the WPE port.
> 
> After talking to teams from Google, Sony, Apple and RedHat during this
> week, everyone thinks using Skia will be a great improvement for the
> GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
> start upstreaming what we have to the WebKit repository and continue
> the work there.
> 
> Points we need to consider:
> 
>- Skia is licensed under the BSD 3-Clause “New” license, which
> should be compatible with WebKit's.
> 
>- The Skia source tree would add about 170MiB to the repository
> under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
> 367MiB and ANGLE 73MiB.
> 
>- We plan to update Skia frequently following Google's
> recommendation. We have already agreed with the Skia maintainers to
> stay in contact and will explore integrating an automated system to
> test updates. We have also discussed Skia's security policy with
> Google, and we will have a procedure in place to incorporate security
> fixes, the latest when we start making releases using Skia.
> 
>- We cannot promise a timeline at the moment but expect refactors
> in the GTK and WPE ports after the initial integration. We have big
> plans for rearchitecting the rendering pipeline to better take
> advantage of GPUs, and we hope we can get rid of some complex code
> while at it.
> 
> Please let us know if you have any questions, we plan to do this job
> sooner rather than later if there are no objections. We are very
> excited about this move since we really think it will be a great step
> ahead for the non Apple ports of WebKit, allowing the project to grow
> even bigger and stronger.
> 
> Best regards,
> 
> - The Igalia team
> 
> -- 
> Carlos Garcia Campos
> ___
> 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] constinit: C++20 tip about constexpr initialization for global variables

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

Now, our baseline is GCC 10, so I would like to introduce useful C++20 feature 
here, constinit.
https://en.cppreference.com/w/cpp/language/constinit

You can annotate the global variables etc. with `constinit`, like,

```
static constinit StaticStringImpl aboutBlankString { "about:blank" };
```

Tthe benefit is that, compiler knows the strong requirement that this variable 
must be initialized at compile-time (constexpr constructors).

Our global constructor warning is just a warning, so compilers typically allow 
compiling and at the very end, it emits a warning as an error.
So, at that time, we don't know what is breaking constexpr condition. For 
example,

```
/Volumes/WebKit/macOS/OpenSource/Source/WTF/wtf/URL.cpp:932:25: error: 
declaration requires a global constructor [-Werror,-Wglobal-constructors]
static StaticStringImpl aboutBlankString { "about:blank" };
```

You can see that *something* in StaticStringImpl breaks `constexpr`, but we 
cannot see what is breaking it, because, when emitting this warning, compiler 
already lost that information (and compiler just already compiled it via non 
constexpr, and at the very end, it emits warnings like this).

But if you annotate this variable with `constinit`, then compiler knows this 
requirement a-priori, thus,

```
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:932:35: error: 
variable does not have a constant initializer
static constinit StaticStringImpl aboutBlankString { "about:blank" };
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:932:8: note: required 
by 'constinit' specifier here
static constinit StaticStringImpl aboutBlankString { "about:blank" };
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WTFString.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/StringImpl.h:43:
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:248:28:
 note: cast that performs the conversions of a reinterpret_cast is not allowed 
in a constant expression
const uint8_t* p = (const uint8_t*)characters;
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:64:40:
 note: in call to 'computeHashImpl(&"about:blank"[0], 11, 0)'
return finalizeAndMaskTop8Bits(computeHashImpl(data, 
characterCount, 0));
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:76:16:
 note: in call to 'computeHashAndMaskTop8Bits(&"about:blank"[0], 11)'
return computeHashAndMaskTop8Bits(characters, 
charactersCount - 1);
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WTFString.h:28:
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/StringImpl.h:1251:89:
 note: in call to 'computeLiteralHashAndMaskTop8Bits("about:blank")'
s_hashFlag8BitBuffer | s_hashFlagDidReportCost | stringKind | 
BufferInternal | (WYHasher::computeLiteralHashAndMaskTop8Bits(characters) << 
s_flagCount), ConstructWithConstExpr)
```

The compiler can tell directly what is breaking `constexpr` condition.

`constinit` is available from GCC 10, so it is now supported in all 
WebKit-supporting compilers.

Best regards,
-Yusuke___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] GCC 10 upgrade and C++20 availability

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

Now, based on milestone, we upgraded GCC requirement from 9.3 to 10.2.
This further unlocks many C++20 features, like <=> operator and constinit
You can see more C++20 features in https://en.cppreference.com/w/cpp/20

Best regards,
-Yusuke___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removal of trailing whitespace

[Yusuke Suzuki via webkit-dev]

I agree that we should not do it because it pollutes change history of files, 
git-blame results, and review-diff in PR.
But at the same time, I think there is no reason to add a new trailing 
whitespace via a new commit.
It is nice if we can enforce this rule only for newly added code (via 
style-checker) not to add new trailing spaces.

-Yusuke

> On Apr 12, 2023, at 10:08 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> WebKi proejctt’s long term policy has been to not do this:
> https://lists.webkit.org/pipermail/webkit-dev/2009-August/009665.html
> 
> I don’t think we should change that.
> 
> - R. Niwa
> 
>> On Apr 12, 2023, at 9:17 AM, Chris Dumez via webkit-dev 
>>  wrote:
>> 
>> I am against this because it adds a lot of noise to patches I am trying to 
>> review.
>> I have seen PRs where white space changes account for more than half the 
>> patch I am trying to review.
>> 
>> Dropping trailing spaces on the lines you’re modifying is OK but in the 
>> whole file is too noisy IMO.
>> 
>> Chris.
>> 
>>> On Apr 12, 2023, at 1:22 AM, Anne van Kesteren via webkit-dev 
>>>  wrote:
>>> 
>>> To reduce the overhead of switching between projects with different
>>> whitespace requirements, I would like to suggest we start being
>>> lenient when trailing whitespace is removed. In particular when a file
>>> is being changed to fix a bug.
>>> 
>>> I could see going even further and enforcing this via the style
>>> checker, if there is appetite for that.
>>> 
>>> Thanks for considering!
>>> ___
>>> 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] Proposal on retiring JIT on Windows

[Yusuke Suzuki via webkit-dev]

The reason is that the patch is reverted because it broke Windows DFG. This is 
not acceptable to us since we have no EWS bots running tests.
Without active maintainers / EWS bots, we cannot land JIT changes since it can 
break Windows, and it becomes huge burden than before (previously there was a 
Windows EWS bot running tests).

This is unfortunate, but if nobody steps up as a maintainer of JSC JIT on 
Windows (it involves adding test-running EWS bots, bug fixes of JSC on Windows 
etc.), then I think only the solution is disabling this feature.

So, if we would like to keep it, we need someone who steps up as a maintainer 
of JIT on Windows, and setting up bots running tests on Windows on EWS.

-Yusuke

> On Mar 25, 2023, at 9:27 PM, Kirsling, Ross  wrote:
> 
> This seems unfortunate and unexpected to me—I thought having a singular 
> Windows port was supposed to mean reduced maintenance burden, since we don't 
> have to divide the number of Windows maintainers into two.
> 
> Although reconciling FTL with Windows' calling convention is a challenge that 
> no one's ever had the time to prioritize, we've had a fully working DFG on 
> Windows for so many years. If we turn that off, I can't imagine it ever being 
> revived again.
> 
> How come the discussion here is immediately about getting rid of such a large 
> swath of functionality instead of starting with consideration of the EWS 
> situation itself?
> 
> Ross
> From: Yusuke Suzuki via webkit-dev 
> Sent: Sunday, March 26, 2023 7:23:04 AM
> To: Fujii Hironori ; Brent Fulgham 
> ; Mark Lam 
> Cc: WebKit Development 
> Subject: Re: [webkit-dev] Proposal on retiring JIT on Windows
>  
>> How about LLInt? LLInt has some Windows specific code.
>> Can I revert the change if the JSC team breaks Windows port even though we 
>> have no EWS nor maintainers?
> 
> I think, ultimately, we cannot guarantee that it is working given that there 
> is no EWS bots running tests on Windows, it means it is not debuggable to us.
> Frequency of breakage on LLInt would be smaller than breakage on JIT. But if 
> it happens, then I think reverting is not OK since nothing is doable to JSC 
> team.
> 
> @Brent @Mark What is your thought and plan?
> 
> -Yusuke
> 
>> On Mar 25, 2023, at 3:02 PM, Fujii Hironori  wrote:
>> 
>> It sounds reasonable. I don't object to removing Windows JIT support.
>> 
>> How about LLInt? LLInt has some Windows specific code.
>> Can I revert the change if the JSC team breaks Windows port even though we 
>> have no EWS nor maintainers?
>> 
>> On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> Hello,
>> 
>> I would like to propose retiring JIT on Windows JavaScriptCore.
>> Recently, Apple Windows EWS bots get removed. As a result, there is no 
>> test-running EWS bots on Windows.
>> 
>> This can work for the other part of WebKit since other ports EWS bots are 
>> running tests. However this does not work well for JSC.
>> Compile-tests is not sufficient for JIT since JIT is dynamically generated. 
>> And JIT is very architecture and platform specific.
>> Windows has different ABI, different calling convention, and register usage. 
>> JIT on Windows has very specific things.
>> 
>> Now, because there is no running EWS bots on Windows, it is not possible to 
>> catch Windows specific JIT related issues before landing.
>> Recently, JSC DFG patch has been reverted because Windows gets broken[1]. 
>> But this puts high burden to JSC maintenance since
>> there is no way to test it before landing, and it makes DFG changes very 
>> hard due to Windows.
>> 
>> So, given that there is no active maintainers of Windows JSC JIT and no EWS 
>> bots running tests, I propose retiring JIT on Windows.
>> 
>> [1]: 
>> https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3
>> 
>> -Yusuke
>> ___
>> 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] Proposal on retiring JIT on Windows

[Yusuke Suzuki via webkit-dev]

> How about LLInt? LLInt has some Windows specific code.
> Can I revert the change if the JSC team breaks Windows port even though we 
> have no EWS nor maintainers?

I think, ultimately, we cannot guarantee that it is working given that there is 
no EWS bots running tests on Windows, it means it is not debuggable to us.
Frequency of breakage on LLInt would be smaller than breakage on JIT. But if it 
happens, then I think reverting is not OK since nothing is doable to JSC team.

@Brent @Mark What is your thought and plan?

-Yusuke

> On Mar 25, 2023, at 3:02 PM, Fujii Hironori  wrote:
> 
> It sounds reasonable. I don't object to removing Windows JIT support.
> 
> How about LLInt? LLInt has some Windows specific code.
> Can I revert the change if the JSC team breaks Windows port even though we 
> have no EWS nor maintainers?
> 
> On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
>> Hello,
>> 
>> I would like to propose retiring JIT on Windows JavaScriptCore.
>> Recently, Apple Windows EWS bots get removed. As a result, there is no 
>> test-running EWS bots on Windows.
>> 
>> This can work for the other part of WebKit since other ports EWS bots are 
>> running tests. However this does not work well for JSC.
>> Compile-tests is not sufficient for JIT since JIT is dynamically generated. 
>> And JIT is very architecture and platform specific.
>> Windows has different ABI, different calling convention, and register usage. 
>> JIT on Windows has very specific things.
>> 
>> Now, because there is no running EWS bots on Windows, it is not possible to 
>> catch Windows specific JIT related issues before landing.
>> Recently, JSC DFG patch has been reverted because Windows gets broken[1]. 
>> But this puts high burden to JSC maintenance since
>> there is no way to test it before landing, and it makes DFG changes very 
>> hard due to Windows.
>> 
>> So, given that there is no active maintainers of Windows JSC JIT and no EWS 
>> bots running tests, I propose retiring JIT on Windows.
>> 
>> [1]: 
>> https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3
>> 
>> -Yusuke
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Proposal on retiring JIT on Windows

[Yusuke Suzuki via webkit-dev]

Hello,

I would like to propose retiring JIT on Windows JavaScriptCore.
Recently, Apple Windows EWS bots get removed. As a result, there is no 
test-running EWS bots on Windows.

This can work for the other part of WebKit since other ports EWS bots are 
running tests. However this does not work well for JSC.
Compile-tests is not sufficient for JIT since JIT is dynamically generated. And 
JIT is very architecture and platform specific.
Windows has different ABI, different calling convention, and register usage. 
JIT on Windows has very specific things.

Now, because there is no running EWS bots on Windows, it is not possible to 
catch Windows specific JIT related issues before landing.
Recently, JSC DFG patch has been reverted because Windows gets broken[1]. But 
this puts high burden to JSC maintenance since
there is no way to test it before landing, and it makes DFG changes very hard 
due to Windows.

So, given that there is no active maintainers of Windows JSC JIT and no EWS 
bots running tests, I propose retiring JIT on Windows.

[1]: 
https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3

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

Re: [webkit-dev] Remove the version labels in GitHub

[Yusuke Suzuki via webkit-dev]

I also would like to propose removing Version label asking in git-webkit when 
creating a bugzilla entry.
This was not happening when using webkit-patch.
Given that we have no consensus on adding this, I think this is a regression.

-Yusuke

> On Nov 14, 2022, at 2:38 PM, Darin Adler via webkit-dev 
>  wrote:
> 
> A couple days ago I created a pull request for part of this:
> 
> https://github.com/WebKit/WebKit/pull/6434
> Anyone interested in reviewing?
> 
> — 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] Style guide: enforce `while (true)` over `for (; ; )`

[Yusuke Suzuki via webkit-dev]

+1

-Yusuke

> On Oct 5, 2022, at 5:07 PM, Tim Nguyen via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> The WebKit codebase has an inconsistent mix of `while (true)` and `for (;;)`. 
> Given 2/3 of the usages are `while (true)` and only 1/3 is `for (;;)` from 
> code search, I would suggest enforcing `while (true)`. I also think it is 
> generally more explicit and readable than `for (;;)`. If everyone agrees, 
> I’ll enforce this via webkit-style, so we can end up in a consistent place.
> 
> What does everyone think?
> 
> Cheers,
> Tim
> ___
> 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] Justin Michaud is now a WebKit Reviewer

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

I’m pleased to announce that Justin Michaud is now a WebKit Reviewer :)

Justin started his WebKit contributions from CSS area and expanded it to 
JavaScriptCore too.
He landed many great optimizations and improvements in JSC and fixed various 
super complicated compiler and runtime bugs.

Congratulation Justin!

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

[Yusuke Suzuki via webkit-dev]

Another idea (not formally proposing): Safari extension to bring Bugzilla's 
good points to GitHub UI.

I tried writing random userscripts, and while threaded comments for commit 
message / conversation view while reviewing are still missing,
I got some UI to make comment on commit message easier while reviewing.
Good thing is that we can bring interesting things to GitHub without changing 
underlying protocol much.
Bad thing is it can be fragile.

Anyway, I hope we can have a solution :)

-Yusuke

> On May 10, 2022, at 8:50 PM, Yusuke Suzuki via webkit-dev 
>  wrote:
> 
> 
> 
>> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> 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,
> 
> I'm happy that this is noted explicitly!
> Do we have some of candidate plans that make reviewing experience better?
> For reviewing, to me, this is the only problem in GitHub.
> 
> -Yusuke
> 
>> 
>> 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

___
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

[Yusuke Suzuki via webkit-dev]

> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> 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,

I'm happy that this is noted explicitly!
Do we have some of candidate plans that make reviewing experience better?
For reviewing, to me, this is the only problem in GitHub.

-Yusuke

> 
> 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] JSC broken on s390x

[Yusuke Suzuki via webkit-dev]

Do you have a s390x machine which can be accessible to JSC developers?
I think, probably, only someone having this machine access can fix the problem.

-Yusuke

> On Apr 19, 2022, at 5:23 AM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> Hi,
> 
> I want to call attention to:
> 
> https://bugs.webkit.org/show_bug.cgi?id=238956
> 
> It breaks JSC on s390x. If anybody is interested in this architecture, or 
> cares about WebKitGTK updates in Fedora (this issue will be a blocker), any 
> help would be much appreciated. :)
> 
> I've also informed Red Hat that this architecture needs more help.
> 
> 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] ChangeLog Deprecation Plans

[Yusuke Suzuki via webkit-dev]

> On Apr 18, 2022, at 5:38 PM, Michael Catanzaro  wrote:
> 
> 
> On Mon, Apr 18 2022 at 02:55:08 PM -0700, Yusuke Suzuki  
> wrote:
>> I think this is important. We are using commit message / ChangeLog as a 
>> document tied to the change, and we are writing very detailed description to 
>> make the intention / design of the change clear and making it as a good 
>> document when we read the change via git-blame, bisect, using that header, 
>> investigating how it works etc.
>> To make / keep this commit message / ChangeLog helpful, we need review, and 
>> I think reviewing of these messages is critical to keep usefulness of them.
> 
> I agree with all of the above. Actually, I'd suggest that the transition to 
> git is a good opportunity to become a little stricter with commit message 
> format than we historically have been. Except for trivial/obvious changes, 
> more detail is better.
> 
> However, we don't need ChangeLog files in the repo or inline review comments 
> to do this. I'm sure we can make do with the normal GitHub review UI.

GitHub (probably, Phabricator too) does not have UI to review commit message.
Also, showing commit message in an attached diff is pretty much similar to how 
Gerrit etc. shows the commit message for review. (Gerrit shows "Commit Message" 
diff).

> 
>> I think COMMIT_MESSAGE proposal has various good benefits.
>> 1. We can review commit mesasges.
>> 2. In local development, we can commit expected COMMIT_MESSAGE file directly 
>> in our tree. We can eventually add more and more detailed information to 
>> this file while local development continues, and we can also revert 
>> COMMIT_MESSAGE change since it can be commited in the local branch.
> 
> This has few advantages over using 'git commit --amend' or 'git rebase -i'. 
> It would also be a custom, WebKit-specific part of our workflow. This is a 
> good opportunity to remove as many WebKit-isms from our contribution process 
> as possible, to make it easier for people who are not familiar with the 
> project to contribute more easily. I suggest we at least try to do things 
> like most other open source projects first, and only implement custom 
> solutions if that fails.

Many projects are using multiple commits in one PR. Some projects require 
squashed merge (e.g. CoreCLR 
https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#suggested-workflow,
 https://github.blog/2016-04-01-squash-your-commits/ 
<https://github.blog/2016-04-01-squash-your-commits/>), and some projects just 
merge all of them. Because of the importance of performance / regression 
bisection, we must require landing a PR as one commit, so we need a way to 
squash commits.
If we would like to sane commit message for merged commits, we need to chose 
COMMIT_MESSAGE-like separated metadata for message or squashing manually.
Having separated metadata is much easier for development than manually 
squashing commits and messages because we can keep the final commit message 
safely even while changing history / code in this branch, and it was how 
webkit-patch worked.

> 
>> 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.
> 
> Developers are NOT used to writing commit messages in a file named 
> COMMIT_MESSAGE.

No. Various OSS projects require writing commit message separately from 
git-commit's message.
Chromium requires writing separate commit message data to upload a patch to 
Gerrit (git-cl).
And probably LLVM is too. (Using arc tool to upload a change to Phabricator).
They are conceptually the same to COMMIT_MESSAGE: managing non git-commit 
message for upstreaming.

Also, I'm fine if we can separately keep this message from git-commit. 
COMMIT_MESSAGE is one possible way.
But if we would like to have git-cl like tool which manages message separately 
from git-commit messages, then it is also fine. (but in that case, how to 
review this commit message is yet another problem).

> 
>> 3. This solves the problem how to squash multiple commits in one PR. 
>> Merge-queue can just look at this file and use this as a commit message when 
>> squashing and landing. This means that, in a PR, we can push multiple small 
>> commits in our PR branch.
> 
> What is the advantage to doing this, though? It's best if the commits in yo

Re: [webkit-dev] ChangeLog Deprecation Plans

[Yusuke Suzuki via webkit-dev]

> On Apr 18, 2022, at 12:51 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Mon, Apr 18 2022 at 08:30:04 AM -0700, Jonathan Bedard via webkit-dev 
>  wrote:
>> 2) We need a way to comment on commit messages in review
>>  Current tooling sets the pull request description as the commit 
>> message, “Quote Reply” kind of provides a way to inline comment, although 
>> it´s not the formal review UI
>>  Proposal: Tooling should support a “COMMIT_MESSAGE” file in each pull 
>> request commit that becomes COMMIT_MESSAGE when a pull request is landed
> 
> Although it's inconvenient that we won't be able to leave inline comments on 
> commit messages anymore, is that really so serious a loss that it requires a 
> strange workaround? It just doesn't seem like a very big deal? We can copy 
> and paste and quote when we suggest changes in commit messages.

I think this is important. We are using commit message / ChangeLog as a 
document tied to the change, and we are writing very detailed description to 
make the intention / design of the change clear and making it as a good 
document when we read the change via git-blame, bisect, using that header, 
investigating how it works etc.
To make / keep this commit message / ChangeLog helpful, we need review, and I 
think reviewing of these messages is critical to keep usefulness of them.

I think COMMIT_MESSAGE proposal has various good benefits.

1. We can review commit mesasges.
2. In local development, we can commit expected COMMIT_MESSAGE file directly in 
our tree. We can eventually add more and more detailed information to this file 
while local development continues, and we can also revert COMMIT_MESSAGE change 
since it can be commited in the local branch. 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.
3. This solves the problem how to squash multiple commits in one PR. 
Merge-queue can just look at this file and use this as a commit message when 
squashing and landing. This means that, in a PR, we can push multiple small 
commits in our PR branch. Merge-queue can get canonical COMMIT_MESSAGE when 
squashing, so keeping one-commit-per-one-PR in the upstream branch is easy. 
This allows normal git-based development workflow while keeping commit-message 
format canonical: creating a topic branch, committing many small changes to 
this branch, creating a PR, and PR gets merged into the upstream as a single 
commit.

-Yusuke

> 
>>  Proposal: Have Tools/Scripts/git-webkit setup configure hooks in 
>> contributors local git repositories to lay down CommitMessages.history files 
>> on merge, checkout and commit which contain the last 5000 commit messages. 
>> We can put these in similar places to where ChangeLogs are today, although 
>> we would likely want them in fewer places because this will increase local 
>> compute time on many git operations. We could also make this a configurable 
>> setting so that engineers who are more comfortable with the raw command line 
>> tooling do not have to deal with slower git operations.
> 
> What's wrong with `git log`?
> 
> There are GUI apps that can visualize your git history if so desired, e.g. 
> GNOME has gitg.
> 
> 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] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

That’s awesome! Thank you for your work!

-Yusuke

> On Mar 9, 2022, at 4:29 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Apple and Sony are finishing updating our build infrastructure to Visual 
> Studio 2022, and we are considering requiring it to build WebKit starting 
> next week.  If anyone has a reason to delay further, please let me know on 
> this list or directly.
> 
>> On Jan 24, 2022, at 1:43 PM, Alex Christensen via webkit-dev 
>>  wrote:
>> 
>> Ok.  We won’t raise the minimum CMake version for all of WebKit right now 
>> then, just on Windows when we start requiring VS2022.
>> 
>>> On Jan 22, 2022, at 1:44 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>>  wrote:
>>> 
>>> On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote:
 While we’re updating things, is there any objection to updating the
 minimum version of CMake required?  Right now it is 3.12, which was
 released in 2018.  Does anyone have any limitations we should consider
 when picking a new minimum version?
 
>>> 
>>> Yes.
>>> 
>>> CMake is one of the core dependencies for GTK and WPE ports, so the
>>> policy of dependencies applies [1]
>>> 
>>> In practical terms that means that we should support the version of
>>> CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.
>>> 
>>> However, If the purpose of raising the version is to take advantage of
>>> the new Visual Studio generator then I don't think raising the minimum
>>> version is needed.
>>> 
>>> As far as I know you can take advantage of newer CMake features (like
>>> support for a newer generator) without needing to raise the minimum
>>> version required.
>>> 
>>> So if you have a newer version of CMake you can simply pass the flag
>>> -G"Visual Studio 17 2022" (or similar). Raising the minimum version
>>> required of CMake is not needed to use a newer CMake generator, using it
>>> can be made optional for those that want (and can) use it.
>>> 
>>> 
>>> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>>> ___
>>> 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] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

It sounds nice! New CMake (3.21~) already supports VS 2022.

-Yusuke

> On Jan 21, 2022, at 10:36 AM, Alex Christensen  wrote:
> 
> Related to the C++20 change, I’m working on moving the Visual Studio build to 
> Visual Studio 2022.  I’ve informed several involved parties directly, but now 
> I’ve informed everyone.  If anyone has a reason not to move to VS2022, please 
> let me know.
> 
>> On Jan 6, 2022, at 2:11 AM, Yusuke Suzuki > <mailto:ysuz...@apple.com>> wrote:
>> 
>> We cannot use char8_t since it is not available in GCC 8.3.0 :)
>> 
>> -Yusuke
>> 
>>> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> I, with great help from several of you, got 
>>> https://bugs.webkit.org/show_bug.cgi?id=233963 
>>> <https://bugs.webkit.org/show_bug.cgi?id=233963> compiling on all 
>>> platforms, but several of the JSC bots are still red.  I’m under the 
>>> impression that they either need a clean build or I’ve missed something.  
>>> Could a JSC bot maintainer look into it?
>>> 
>>>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>> 
>>>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>>>> I recently upgraded GCC requirement to 8.3.0 based
>>>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>>>> (https://trac.webkit.org/changeset/283348/webkit 
>>>>> <https://trac.webkit.org/changeset/283348/webkit>
>>>>> <https://trac.webkit.org/changeset/283348/webkit 
>>>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>>>> As a result, we can use some of C++20 features.
>>>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>>>> be used since GCC 8.3.0 does not support, but some of features can be
>>>>> used, and it is super useful.
>>>> 
>>>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>>>> with C++-20 support and to start using the C++-20 features already
>>>> supported by GCC 8.3.0
>>>> 
>>>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>>>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>>>> features are supported by GCC 8
>>>> 
>>>> Before using them I think it would be a good idea to double-check if
>>>> those are also supported by the minimum version of Clang that we want to
>>>> support.
>>>> And maybe also to check if those are supported by MS Visual C++ ?
>>>> I say maybe because I'm not sure if we support this compiler.
>>>> ___
>>>> 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] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

We cannot use char8_t since it is not available in GCC 8.3.0 :)

-Yusuke

> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> I, with great help from several of you, got 
> https://bugs.webkit.org/show_bug.cgi?id=233963 
> <https://bugs.webkit.org/show_bug.cgi?id=233963> compiling on all platforms, 
> but several of the JSC bots are still red.  I’m under the impression that 
> they either need a clean build or I’ve missed something.  Could a JSC bot 
> maintainer look into it?
> 
>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>> I recently upgraded GCC requirement to 8.3.0 based
>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>> (https://trac.webkit.org/changeset/283348/webkit 
>>> <https://trac.webkit.org/changeset/283348/webkit>
>>> <https://trac.webkit.org/changeset/283348/webkit 
>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>> As a result, we can use some of C++20 features.
>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>> be used since GCC 8.3.0 does not support, but some of features can be
>>> used, and it is super useful.
>> 
>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>> with C++-20 support and to start using the C++-20 features already
>> supported by GCC 8.3.0
>> 
>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>> features are supported by GCC 8
>> 
>> Before using them I think it would be a good idea to double-check if
>> those are also supported by the minimum version of Clang that we want to
>> support.
>> And maybe also to check if those are supported by MS Visual C++ ?
>> I say maybe because I'm not sure if we support this compiler.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

I recently upgraded GCC requirement to 8.3.0 based on 
https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
 
(https://trac.webkit.org/changeset/283348/webkit 
)
As a result, we can use some of C++20 features.
I wonder if we can flip C++20 now. While some of C++20 features cannot be used 
since GCC 8.3.0 does not support, but some of features can be used, and it is 
super useful.
One of the good features is initializer for bit-fields, which can avoid 
uninitialized bit-field bugs.

class A {
bool m_test : 1 : { false };
};

-Yusuke

> On Dec 6, 2021, at 12:52 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> In April 2019 in https://bugs.webkit.org/show_bug.cgi?id=197131 
>  I increased WebKit’s minimum 
> C++ language requirement from C++14 to C++17.  In 2022 I’m planning to 
> increase WebKit’s minimum C++ requirement from C++17 to C++20.  Would April 
> 2022 be a good time to do that?
> ___
> 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] Caio Lima is now a WebKit reviewer

[Yusuke Suzuki via webkit-dev]

Congrats!

-Yusuke

> On Mar 18, 2021, at 3:42 PM, Saam Barati via webkit-dev 
>  wrote:
> 
> Hi folks,
> 
> I'm happy to announce that Caio Lima is now a WebKit reviewer. Send your 
> JavaScriptCore reviews his way!
> 
> Congrats, Caio.
> 
> - Saam
> ___
> 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] Commit Authorship on GitHub

[Yusuke Suzuki via webkit-dev]

> On Dec 1, 2020, at 11:57 AM, Jonathan Bedard  wrote:
> 
> 
> 
>> On Dec 1, 2020, at 1:55 PM, Yusuke Suzuki > <mailto:ysuz...@apple.com>> wrote:
>> 
>> Hi Jonathan!
>> 
>>> On Dec 1, 2020, at 8:22 AM, Jonathan Bedard via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> Hello contributors,
>>> 
>>> I am in the process of modifying one of our Git mirrors of the repository 
>>> for permanent use. As part of that modification, I am repairing authorship 
>>> of historical commits based on contributors.json. This effort includes our 
>>> branches and resolving commits attributed to commit-queue but authored by 
>>> contributors. Once this task of rewriting history is completed, I will push 
>>> the new repository to GitHub to replace the broken mirror that currently 
>>> resides there.
>> 
>> Does it mean that https://github.com/WebKit/WebKit 
>> <https://github.com/WebKit/WebKit> will become an usual repository (not 
>> GitHub sync-ed mirror repository) which is mirrored by ourselves?
>> Previously, when I tried, GitHub-mirrored repository does not invoke 
>> web-hooks correctly, and it was the reason why I needed to create WKR bots.
>> But if WebKit in GitHub repository becomes an usual repository (while it is 
>> mirrored, it is not mirrored by GitHub side), I think this is a good timing 
>> to setting up GitHub <-> slack integration to put commits into #changes and 
>> retiring WKR bot (while WebKitBot exists).
> 
> It does mean that https://github.com/WebKit/WebKit 
> <https://github.com/WebKit/WebKit> will become a normal GitHub repository! 
> That being said, I need to set up the automated syncing before we start using 
> web-hooks.

Cool! Let me know in slack etc. when the repository gets ready. I’ll look into 
GitHub integration for commits and retire WKR feature if GitHub slack 
integration can cover that feature.

-Yusuke


> 
> Jonathan
> 
>> 
>> -Yusuke
>> 
>>> 
>>> Since the new repository will have correctly attributed commits, now is a 
>>> good time to ensure that the email address (or addresses) that you use or 
>>> have used to contribute to WebKit are attached to your GitHub account, 
>>> since this is how GitHub connects a user to their contributions.
>>> 
>>> Also note that GitHub will still just be a mirror for the next few months, 
>>> so there is no requirement to have an account with GitHub yet.
>>> 
>>> Jonathan
>>> ___
>>> 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] Commit Authorship on GitHub

[Yusuke Suzuki via webkit-dev]

Hi Jonathan!

> On Dec 1, 2020, at 8:22 AM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> Hello contributors,
> 
> I am in the process of modifying one of our Git mirrors of the repository for 
> permanent use. As part of that modification, I am repairing authorship of 
> historical commits based on contributors.json. This effort includes our 
> branches and resolving commits attributed to commit-queue but authored by 
> contributors. Once this task of rewriting history is completed, I will push 
> the new repository to GitHub to replace the broken mirror that currently 
> resides there.

Does it mean that https://github.com/WebKit/WebKit 
 will become an usual repository (not GitHub 
sync-ed mirror repository) which is mirrored by ourselves?
Previously, when I tried, GitHub-mirrored repository does not invoke web-hooks 
correctly, and it was the reason why I needed to create WKR bots.
But if WebKit in GitHub repository becomes an usual repository (while it is 
mirrored, it is not mirrored by GitHub side), I think this is a good timing to 
setting up GitHub <-> slack integration to put commits into #changes and 
retiring WKR bot (while WebKitBot exists).

-Yusuke

> 
> Since the new repository will have correctly attributed commits, now is a 
> good time to ensure that the email address (or addresses) that you use or 
> have used to contribute to WebKit are attached to your GitHub account, since 
> this is how GitHub connects a user to their contributions.
> 
> Also note that GitHub will still just be a mirror for the next few months, so 
> there is no requirement to have an account with GitHub yet.
> 
> Jonathan
> ___
> 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] Reminder: include everything that you use in implementation files

[Yusuke Suzuki via webkit-dev]

I think, without EWS / post-build bots using non-unified builds, this is 
difficult to achieve…

-Yusuke

> On Nov 12, 2020, at 4:16 AM, Adrian Perez de Castro via webkit-dev 
>  wrote:
> 
> Hello Peng,
> 
> On Wed, 11 Nov 2020 12:05:18 -0800 "Peng (WebKit) Liu via webkit-dev" 
>  wrote:
> 
>> Any way/option to turn off the unified build completely or partially in a
>> local build? That would be very helpful for a developer to locally verify
>> that header files are included correctly in a patch. Thanks!
> 
> You can use “build-webkit --no-unified-builds” to disable them; though I am
> unsure if this will work for the Mac/iOS ports… It surely works with the
> ports that use CMake (WPE, GTK, JSCOnly), and when using CMake you can also
> use “cmake -DENABLE_UNIFIED_BUILDS=OFF” if you would rather configure and
> build manually.
> 
> I hope this helps.
> 
> Cheers,
> —Adrián
> 
>> Best regards
>> Peng
>> 
>>> On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
>>>  wrote:
>>> 
>>> Hello folks,
>>> 
>>> I'd like to remind everyone to please include what you use in .cpp,  .mm, 
>>> and other files. When reviewing patches, please
>>> ensure that new mentions of classes, structs, etc. within an implementation 
>>> file have a corresponding header include. 
>>> All of our headers have #pragma once, so there is no downside to being more 
>>> explicit.
>>> 
>>> I've been noticing an uptick in the number of unified sources-related build 
>>> failures. I can't remember the last nontrivial patch
>>> I wrote that did *not* include unrelated build fixes. Typically these 
>>> failures aren't found until EWS results come back, reducing developer 
>>> velocity.
>>> And obviosuly it's super annoying to encounter completely unrelated build 
>>> failures that must be nonetheless addressed.
>>> 
>>> Let's all do our part so that hacking on WebKit remains delightful.
>>> 
>>> Thanks,
>>> 
>>> Brian Burg (he/they)
>>>  WebKit Developer Experience
> ___
> 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] Alexey Shvayka is now a WebKit Reviewer

[Yusuke Suzuki]

Hello WebKittens,

I’m pleased to announce that Alexey Shvayka is now a WebKit Reviewer :)

Alexey is very active in JavaScriptCore. He improved JavaScriptCore’s test262 
conformance significantly,
and added various optimizations too. He also landed various DOM patches which 
improved WPT.

Congratulation Alexey!

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

Re: [webkit-dev] WebKit Transition to Git

[Yusuke Suzuki]

> On Oct 5, 2020, at 5:13 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 05.10.2020, 23:41, "Yusuke Suzuki" :
>> I think security component is special in terms of how to handle it already 
>> (e.g. not posting a test with the patch etc.)
>> To me, handling non-security issues in GitHub and security issues in 
>> Bugzilla is OK.
>> By nature, security issues are not open. Since one of our motivation of 
>> moving to GitHub is openness for feedback collection, security issue in 
>> Bugzilla does not matter for this motivation.
>> Ideally, handling both in GitHub is better. But to me, rather than 
>> continuing using Bugzilla, using GitHub for non security issues sounds 
>> improvement.
> 
> To me it sounds as a huge step backwards. Asides from situation with security 
> issues, it has other significant drawbacks in domain of issue triaging and 
> management:
> 
> 1. Sub-par support for linking issues to each other
> 
> 
> Traditional bug tracking systems (like Bugzilla or JIRA) have support of 
> "related" or "linked" issues. Most important relations are
> 
> * A depends on B (B blocks A) - blockers and umbrella issues
> * B is duplicate of A
> * A and B are related in other unspecified way
> 
> All GitHub can offer here now is mentions (and, to some extent, milestones 
> for case of "umbrella issues" [1]). Mention is created every time someone 
> uses "#" (e.g. "#123") in the text of issue or in the comment, where 
> number is a sequential number of issue or pull request [2]. When comment is 
> published in issue A which mentions issue B, there is a pseudo-comment added 
> to B, and subscribers of B receive email notification.
> 
> At first glance this naive approach seems to work, but
> 
> * There is no easily visible list of relations: if you are not closely 
> following all activity on A, to find all issues related to it you have to 
> browse through all its (pseudo-)comments, which in some cases might be long. 
> * There is no *stateful* list of relations: if A was believed to have common 
> source with B, but then it was discovered they are not related, you cannot 
> delete relationship between A and B because there is no relationship, just a 
> set of comments.
> * "#" is not a safe reference format. Sometimes users' comments may 
> have other data in "#" format with a different meaning than 
> references to GitHub issues. For example, may the force be with you if 
> someone pastes gdb or lldb backtrace into comment without escaping it into 
> markdown raw text block (```). Also, GitHub parses mentions in git commit 
> messages, so care must be taken to avoid any occurrences of "#" with 
> a meaning different from reference to issue number.
> 
> ---
> 
> [1] Milestones are not issues themselves, but they establish true two-way 
> stateful relation between issues and their "parent" milestone.
> [2] For some reason they have shared numbering, which means sometimes you may 
> not know what kind of reference is in front of you until you look up its URL 
> or navigate
> 
> 
> 2. Sub-par issue categorization and search
> --
> 
> In traditional bug tracking systems every issue has properties like status, 
> resolution, component, severity/issue type, priority. When new bug is 
> created, user chooses values of these properties, which can be later adjusted 
> by the person doing triaging. They also are used in user-friendly search 
> dialog like [1].
> 
> All GitHub can offer here are custom labels. While in theory they are 
> sufficient to replace pre-defined issue properties, they require disciplined 
> use to be efficient, for example issue must not have mutually exclusive 
> labels. To avoid chaos, GitHub allows setting issue labels only to 
> contributors. However, this puts more work on triagers, and they cannot 
> triage only certain kinds of issues which match their interests by going 
> through results of search query.
> 
> [1] https://bugs.webkit.org/query.cgi
> 
> 
> 3. Sub-par attachments
> --
> 
> Traditional bug trackers allow attaching files to issue. GitHub goes further 
> and allows to attach files to every comment. Enjoy the progress -  now you 
> can look for attached test cases and proposed patches through all comment 
> feed, instead of having them in one place at the top.
> 
> Also, on test cases. You probably like this feature of Bugzilla when you can 
> attach self-contained HTML file to the issue and then simply open it by URL 
> in any

Re: [webkit-dev] WebKit Transition to Git

[Yusuke Suzuki]

I think security component is special in terms of how to handle it already 
(e.g. not posting a test with the patch etc.)
To me, handling non-security issues in GitHub and security issues in Bugzilla 
is OK.
By nature, security issues are not open. Since one of our motivation of moving 
to GitHub is openness for feedback collection, security issue in Bugzilla does 
not matter for this motivation.
Ideally, handling both in GitHub is better. But to me, rather than continuing 
using Bugzilla, using GitHub for non security issues sounds improvement.

-Yusuke

> On Oct 5, 2020, at 12:58 PM, Fujii Hironori  wrote:
> 
> 
> 
> On Tue, Oct 6, 2020 at 12:40 AM Jonathan Bedard  > wrote:
> 
> That's one solution, but even that is somewhat insufficient because we don’t 
> want to give someone access to every security issue just to give access to a 
> single one. One of the solutions we’ve discussed is to migrate bugs component 
> by component, the security component may stay on bugzilla indefinitely.
> 
> 
>  I don't like this idea of using GitHub issue tracker and Bugzilla together. 
> Let's keep using Bugzilla for all components.
> ___
> 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 Transition to Git

[Yusuke Suzuki]

GitHub is planning to have review revisions in 2020/Q4.
So, when WebKit repository is migrated, we already have that in GitHub builtin 
review tool :)

https://github.com/github/roadmap/issues/54 


Best regards,
Yusuke

> On Oct 3, 2020, at 5:18 PM, Michael Catanzaro  wrote:
> 
> On Sat, Oct 3, 2020 at 9:52 pm, Konstantin Tokarev  wrote:
>> If I understand correctly, there is no way in GitHub UI to see a difference 
>> between
>> patches submitted at step 1 and step 3. It's still possible to see old 
>> version of patches
>> if you navigate to old commit hash, but that's not for long as they can be 
>> garbage
>> collected by GitHub because they don't belong to git branch anymore.
> 
> If we are really seriously concerned about this... it's not a problem with 
> GitLab. At least, I can still view diffs between different revisions of merge 
> requests from two years ago, and the changes seem to be stored forever. At 
> least I still can view diffs from years ago. E.g.:
> 
> https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=27669&start_sha=0c020384b602c9e1f0e8ec9e491d1951e8feadf7
> 
> Unfortunately it's sometimes less useful than I might have hoped, because 
> rebases bring in a bunch of totally unrelated changes, e.g.:
> 
> https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/62/diffs?diff_id=28036&start_sha=043b5fc32f4f9263d393c9de83e1b33123c5
> 
> 
> 
> ___
> 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-changes] [264332] trunk/Source

[Yusuke Suzuki]

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

Re: [webkit-dev] New EWS queues for tvOS and watchOS

[Yusuke Suzuki]

Nice,

Is watchOS build ARMv7k? Or is it ARM64_32?

-Yusuke

> On Jul 11, 2020, at 8:09 AM, Aakash Jain  wrote:
> 
> Hi Everyone,
> 
> I am happy to announce that we have added new EWS queues for tvOS and 
> watchOS. From now on, you would see four new status bubbles (on Bugzilla bug) 
> named: tv, tv-sim, watch, watch-sim (corresponding to device and simulator 
> builds for watchOS and tvOS). This should help in preventing any accidental 
> build breakage on these platforms.
> 
> Please let me know if you notice any issue.
> 
> 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

[webkit-dev] @webkitbot in slack is available

[Yusuke Suzuki]

Hi all,

Some of you already noticed (and used it), webkitbot is available in WebKit 
slack's #dev channel.
We can use it like the following as you know in IRC days.

@webkitbot revert 260220 Crash several JSTests

Then, webkitbot opens bugzilla issue and uploads revert patch for you.

In early development phase, Simon heavily used and reported a lot of bugs and 
improvements.
Those are fixed and integrated well into slack @webkitbot and it is working 
well.
Thanks so much!

-Yusuke

=

The implementation is uploaded in https://bugs.webkit.org/show_bug.cgi?id=211707

___
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

[Yusuke Suzuki]

In JSC EWS bots. For the other Debug EWS bots, (Like, WebCore Debug builds), I 
have no strong opinion.

-Yusuke

> On Jun 17, 2020, at 6:07 PM, Yusuke Suzuki  wrote:
> 
> For EWS, we are running Release build right now. So in terms of stack traces, 
> nothing is changed.
> 
> -Yusuke
> 
>> On Jun 17, 2020, at 5:21 PM, Alexey Proskuryakov > <mailto:a...@webkit.org>> wrote:
>> 
>> 
>> I frequently find it critically useful to see stack traces from debug 
>> builds, because of no inlining. So I don't think that we should do this. A 
>> local build does not help when the issue is not readily reproducible.
>> 
>> - Alexey
>> 
>> 
>>> 17 июня 2020 г., в 1:36 PM, Mark Lam >> <mailto:mark@apple.com>> написал(а):
>>> 
>>> 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.
>>> 
>>> 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 <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

___
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

[Yusuke Suzuki]

For EWS, we are running Release build right now. So in terms of stack traces, 
nothing is changed.

-Yusuke

> On Jun 17, 2020, at 5:21 PM, Alexey Proskuryakov  wrote:
> 
> 
> I frequently find it critically useful to see stack traces from debug builds, 
> because of no inlining. So I don't think that we should do this. A local 
> build does not help when the issue is not readily reproducible.
> 
> - Alexey
> 
> 
>> 17 июня 2020 г., в 1:36 PM, Mark Lam > > написал(а):
>> 
>> 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

Re: [webkit-dev] Accidental binary bloating via C/C++ class/struct + Objective-C

[Yusuke Suzuki]

> On Jan 13, 2020, at 19:28, Darin Adler  wrote:
> 
>> On Jan 13, 2020, at 5:52 PM, Yusuke Suzuki > <mailto:ysuz...@apple.com>> wrote:
>> 
>> We can purge type-encoding-string if we use Objective-C NS_DIRECT feature 
>> (which makes Objective-C function as C function calling convention, removing 
>> metadata).
>> However, this does not work universally: with NS_DIRECT, Objective-C 
>> override does not work. This means we need to be extra-careful when using it.
> 
> Yes, we need to be careful, but NS_DIRECT is likely to have more benefit than 
> just binary shrinking, and it should do even more binary shrinking than 
> hiding types from Objective-C. Use of NS_DIRECT will likely help performance, 
> sometimes in a measurable way.

Right. I guess that many parts of code requiring high-performance are already 
in C++ in WebKit project.
But still, we should explore the places we can use NS_DIRECT, e.g. internal 
accessors of Objective-C classes. We could get benefit.
One thing I would like to check is JSC APIs, since typical operation inside JSC 
APIs are very small.
If one API is calling another internal objective-C methods, which are never 
overridden, we could get benefit by annotating these internal methods w/ 
NS_DIRECT.

> 
> However, besides the risk of making something “non-overridable”, I think it’s 
> only available in new versions of the clang compiler.
> 
>> So, as a simple, but effective work-around, in the above patch, we 
>> introduced NakedRef / NakedPtr. This is basically raw pointer / raw 
>> reference to T, with a wrapper class.
>> This leverages the behavior of Objective-C compiler’s mechanism “one-level 
>> deep type information collection”. Since NakedRef / NakedPtr 
>> introduces one-level deep field,
>> Objective-C compiler does not collect the type information of T if 
>> NakedPtr is included in the fields / signatures, while the compiler 
>> collects information when T* is used.
> 
> Very exciting. Does this cover all the cases we care about? Does come up for 
> types that are not references or pointers? Maybe we can pass arguments by 
> const reference? What about return values?

Many cases are covered. Non-covered part is code passing C/C++ struct/class as 
values.
We could shrink it if we allocate it by using std::unique_ptr / RefPtr / Ref 
and passing std::unique_ptr&& / RefPtr&& / Ref&& (since they are also 
introducing one-level nested structure).
For the places using raw pointers / raw references, we can attempt to use 
NakedPtr<> / NakedRef<>.

> 
>> ## Future work
>> 
>> We would like to avoid including such types accidentally in Objective-C. We 
>> should introduce build-time hook script which detects such a thing.
>> I uploaded the PoC script in https://bugs.webkit.org/show_bug.cgi?id=205968 
>> <https://bugs.webkit.org/show_bug.cgi?id=205968>, and I’m personally 
>> planning to introduce such a hook into a part of build process.
> 
> Beautiful. Well worth doing.

Yeah, we should do it. While the above two patches removed too large 
type-encoding-strings (like, one type-encoding-string took more than 100KB…),
we still have many of very long type-encoding-strings (like 6KB). Removing this 
can reduce binary-size. And it could be nice for performance if this string is 
used some part of Objective-C runtime hash-table etc. (Not sure whether it 
happens) by avoiding including such a large string into a hash table.

-Yusuke

> 
> Thanks!
> 
> — Darin

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

[webkit-dev] Accidental binary bloating via C/C++ class/struct + Objective-C

[Yusuke Suzuki]

Hello WebKittens,

I recently striped 830KB binary size in WebKit just by using a work-around.
This email describes what happened so far, to prevent from happening again.

## Problem

When C/C++ struct/class is included in field types and method types in 
Objective-C, Objective-C compiler puts type-enconding-string which gathers type 
information one-leve deep for C/C++ struct/class if

1. The type is a pointer to C/C++ struct/class
2. The type is a value of C/C++ struct/class
3. The type is a reference to C/C++ struct/class

However, our WebKit C/C++ struct/class is typically very complex type using a 
lot of templates. Unfortunately, Objective-C compiler includes expanded 
template definition as a string and adds it as a type-enconding-string into the 
release binary!

For example, https://trac.webkit.org/changeset/254152/webkit 
 is removing JSC::VM& from 
Objective-C signature, and it reduces 200KB binary size!
Another example is https://trac.webkit.org/changeset/254241/webkit 
, which removes a lot of 
WebCore::WebView* etc. from Objective-C method signature, and reduces 630KB 
binary.

## Solution for now

We can purge type-encoding-string if we use Objective-C NS_DIRECT feature 
(which makes Objective-C function as C function calling convention, removing 
metadata).
However, this does not work universally: with NS_DIRECT, Objective-C override 
does not work. This means we need to be extra-careful when using it.

So, as a simple, but effective work-around, in the above patch, we introduced 
NakedRef / NakedPtr. This is basically raw pointer / raw reference to T, 
with a wrapper class.
This leverages the behavior of Objective-C compiler’s mechanism “one-level deep 
type information collection”. Since NakedRef / NakedPtr introduces 
one-level deep field,
Objective-C compiler does not collect the type information of T if NakedPtr 
is included in the fields / signatures, while the compiler collects information 
when T* is used.

So, if you are using T& / T* C/C++ struct/class in Objective-C, let’s convert 
it to NakedRef / NakedPtr. Then you could save much binary size 
immediately without causing any performance problem.

## Future work

We would like to avoid including such types accidentally in Objective-C. We 
should introduce build-time hook script which detects such a thing.
I uploaded the PoC script in https://bugs.webkit.org/show_bug.cgi?id=205968 
, and I’m personally planning 
to introduce such a hook into a part of build process.


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

Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

[Yusuke Suzuki]

> On Nov 1, 2019, at 11:53, Michael Catanzaro  wrote:
> 
> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:
>> Namely, some people write a lambda as:
>> auto x = [] () { }
>> with a space between [] and () while others would write it as:
>> auto x = []() { }
> 
> 🔧: I omit the () when there are no parameters, as in these examples.
> 
> No preference on spacing.

I like having a space here, because this rule is simpler to me.
If we always have a space between them, this is clear that the above case is 
written in `[] { }` instead of `[]{ }`.

-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

[webkit-dev] PSA: JSC interface is changed from passing ExecState* to passing lexical JSGlobalObject*

[Yusuke Suzuki]

Hello WebKittens,

We did long-wanted refactoring: JSC runtime functions start getting lexical 
realm JSGlobalObject* instead of ExecState*.
Since this slightly changes how we interact with JSC, we would like to show 
what is changed.

This refactoring involves several changes.

1. JSC interface starts getting JSGlobalObject* instead of ExecState*.
2. ExecState* is consistently renamed to CallFrame*. And it is used only when 
CallFrame* is actually required (accessing arguments etc.) And the name 
`ExecState*` is removed from the tree.

Previously we are using `ExecState*`. But this caused multiple problems so far. 
Here is the motivation behind this change.

1. Fix so many bugs in JSC, and makes JSC’s inlining finally sane

ExecState* is simply wrong in various cases. We are getting lexical 
JSGlobalObject* by calling `ExecState::lexicalGlobalObject()`. But it returns 
wrong value if the current function is inlined in DFG/FTL. ExecState is 
pointing the whole function’s CallFrame. And returned `JSGlobalObject*` is 
lexical JSGlobalObject* of top-most function. If inlined function has different 
lexical JSGlobalObject* from the top-most one, we are getting wrong 
JSGlobalObject*. Getting `CodeBlock*` from ExecState* is also wrong. We had 
multiple places that is getting CodeBlock to get strict-mode flag, and this 
code does not consider about inlining. Instead, we pass lexical JSGlobalObject* 
explicitly. This change makes fixing these issues very easy.

2. Clear separation between CallFrame* and JSGlobalObject*, making API clean

CallFrame* is only used when we actually want to access CallFrame* (to get 
arguments etc.). Previously, we are using CallFrame* as an useful abstraction 
to offer an access to various things including lexical JSGlobalObject*. But 
since this is CallFrame*, it exist only after executing some JS code. So if we 
want to call JSC C++ runtime functions without JS code (calling JS runtime 
things directly from C++ world), we do not have ExecState* at all at that time. 
To make it OK, we invented `globalExec()`, which is saying CallFrame*, but in 
fact, it was not a CallFrame*. It exists only for calling these C++ runtime 
functions when CallFrame* does not exist yet. This is ugly and we really wanted 
to remove this. It is now finally removed in 99% of code. Through this 
refactoring, we found multiple places that is accessing |thisValue| etc. while 
it should not have any CallFrame*. So they are accessing wrong thing because 
CallFrame* offers the way to access the wrong thing. We should not offer such a 
wrong abstraction.
And now, we can pass lexical JSGlobalObject* explicitly. Previously, we do not 
have a good way to create ExecState* conveniently. So we just randomly pass 
accessible ExecState* to C++ runtime functions. This looks working, but it is 
wrong when we consider about lexical JSGlobalObject* carefully. Now interface 
explicitly requires lexical JSGlobalObject*, so we can pass the correct 
JSGlobalObject* explicitly.

3. Steps towards putting all JSCells into IsoSubspace

JSC had very fancy hack: all callable JS cells must be small enough (it can be 
allocated in MarkedBlock). This was originally required to make 
`ExecState::vm()` function super fast. We are calling this so frequently and we 
needed to keep it fast. And we can make it fast if we have such a weird 
guarantee. But it turned out that this assumption is not good one for the world 
putting all JSCells into IsoSubspace. We would like to introduce some 
optimizations to IsoSubspace to make it scalable to various JSCell types. But 
this optimization requires that the above assumption is discarded. To make it 
work, we do this refactoring and now we get VM& from JSGlobalObject instead of 
ExecState.

I’m now doing some follow-up work which makes things more solid. And I’m 
planning to do some minor refactoring, like, naming things consistently etc.
I’m also planning to fix various bugs found while doing this refactoring.
And…, this change paves the way to (3), which I’m currently focusing on :)

Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Can we remove XXX.order files in the tree

[Yusuke Suzuki]

What benchmark do we use to track this order files’ improvement? If I just 
remove these files now, can perf bot tell us the results?

Best regards,
Yusuke Suzuki

> On Oct 17, 2019, at 15:42, Stephanie  wrote:
> 
> These files haven't been updated in years so I doubt they're particularly 
> helpful.  They were at one time measurable launch time wins for hdd machines 
> and thats what we need to validate won't regress.
> 
> -- Stephanie
> 
>> On Oct 17, 2019, at 3:05 PM, Yusuke Suzuki  wrote:
>> 
>> Hello WebKittens!
>> 
>> Our XXX.order file (e.g. JavaScriptCore.order) is not updated so long. The 
>> content is already stale, and I think this is no longer effective.
>> Can we just remove these XXX.order files?
>> 
>> -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

[webkit-dev] Can we remove XXX.order files in the tree

[Yusuke Suzuki]

Hello WebKittens!

Our XXX.order file (e.g. JavaScriptCore.order) is not updated so long. The 
content is already stale, and I think this is no longer effective.
Can we just remove these XXX.order files?

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

Re: [webkit-dev] virtual destructor annotations in subclasses

[Yusuke Suzuki]

While I don’t have any opinion about adding override on methods, I would like 
to see more `final` annotation in derived classes’ header when the classes are 
final and inherits something.
In JSC, we leverage this `final` information in `jsCast<>` and `jsDynamicCast` 
to optimize the generated code[1]. So, annotating `final` on JS classes 
actually changes the generated code and makes it optimized.

[1]: If the given JS class is annotated as `final`, we can skip traversing 
subclasses when doing `jsDynamicCast`. We can use this 
information by `std::is_final`.

-Yusuke

> On Oct 8, 2019, at 19:15, Ryosuke Niwa  wrote:
> 
> On Tue, Oct 8, 2019 at 4:24 PM Yury Semikhatsky  > wrote:
> 
> This question came up in a code review where I annotated subclass's 
> destructor with 'override':
> 
> class SuperClass {
> public:
>   virtual ~SuperClass() {}
> };
> 
> class Subclass : public SuperClass {
> public:
>   ~Subclass() override;
> };
> 
> The style guide recommends 
>  
> annotating overriden methods with either 'override' or 'final'. At the same 
> time with a very few exceptions, the vast majority of the subclasses in 
> WebKit annotate their destructors with 'virtual' keyword. It might be because 
> some of the code predates c++11 and virtual was the default choice back then. 
> In any case it prevents the compiler from generating errors when super 
> destructor is accidentally not made virtual.
> 
> So my question is if there is a reason to exempt destructors from the above 
> rule and mark them virtual in subclasses or they should be annotated with 
> override/final similar to other virtual methods?
> 
> In the latter case we could update existing code once  by automatically 
> generating fix with clang-tidy.
> 
> I don't have an opinion either way about the actual style but I'm against 
> adding override everywhere en masse the same way we don't land a bunch of 
> whitespace or other style tidy ups. If we were to decide that we want to add 
> override, that should happen over time as people touch different classes and 
> files.
> 
> - 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] Drop x86 (32bit) JIT backend

[Yusuke Suzuki]

Thanks!

> On Sep 16, 2019, at 4:39 AM, Xan  wrote:
> 
> Hi all,
> 
> We at Igalia use the x86 32bit port for testing, prototyping, etc, in our 
> 32bit work. We recently added a JSC EWS x86 instance.
> That being said only the LLInt tier is working properly at the moment, and if 
> the maintenance of the JIT code is a big burden we think it makes sense to 
> remove it.

Yes, x86 adds many special logic. You can see the actual diff, which involves 
many “only for x86” logic involving weird stack push/pop.
And it is not well-abstracted. As a result, changes are in all of our JIT tiers 
(except for FTL b/c we are not supporting x86 in FTL) :(
https://trac.webkit.org/changeset/249880/webkit 
<https://trac.webkit.org/changeset/249880/webkit>

YarrJIT has HAVE_INITIAL_START_REG ifdef and separate logic, which is only for 
x86. All the other platforms including ARMv7 do not require this.
If this architecture has enough # of registers (like, MIPS), keeping it would 
be much easier.
But it only has very few registers and this makes x86 special compared to the 
other 32bit architectures.
I also note that x86 JIT is not working for at least 3 months. I found that x86 
callee-save-register definition is broken at some point[1].

[1]: https://trac.webkit.org/changeset/249830/webkit 
<https://trac.webkit.org/changeset/249830/webkit>

> 
> This already happened during the weekend, so I guess this can count as an 
> after the fact tacit agreement. In the future we'd appreciate if we could 
> have at least a full week day (including Europe) to discuss these kinds of 
> changes though.

OK, I see.

-Yusuke

> 
> Cheers,
> Xan (on behalf of Igalia's compilers team)
> 
> On Sat, Sep 14, 2019 at 9:32 PM Yusuke Suzuki  <mailto:ysuz...@apple.com>> wrote:
> Thanks!
> 
> I think we are not testing x86 JIT configuration, and nobody is seriously 
> using it (Default build option for c86 is no JIT). Removed :D
> 
> [1]: https://trac.webkit.org/changeset/249830/webkit 
> <https://trac.webkit.org/changeset/249830/webkit>
> 
> Best regards,
> Yusuke Suzuki
> 
>> On Sep 13, 2019, at 15:08, Geoffrey Garen > <mailto:gga...@apple.com>> wrote:
>> 
>> No objection.
>> 
>> Geoff
>> 
>>> On Sep 13, 2019, at 1:39 PM, Yusuke Suzuki >> <mailto:ysuz...@apple.com>> 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 <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Drop x86 (32bit) JIT backend

[Yusuke Suzuki]

Thanks!

I think we are not testing x86 JIT configuration, and nobody is seriously using 
it (Default build option for c86 is no JIT). Removed :D

[1]: https://trac.webkit.org/changeset/249830/webkit

Best regards,
Yusuke Suzuki

> On Sep 13, 2019, at 15:08, Geoffrey Garen  wrote:
> 
> 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] Drop x86 (32bit) JIT backend

[Yusuke Suzuki]

I uploaded the patch for this change.
https://bugs.webkit.org/show_bug.cgi?id=201790 
<https://bugs.webkit.org/show_bug.cgi?id=201790>

-Yusuke

> On Sep 13, 2019, at 15:09, Geoffrey Garen  wrote:
> 
> 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

[webkit-dev] Drop x86 (32bit) JIT backend

[Yusuke Suzuki]

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

Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

[Yusuke Suzuki]

Note that style-checker change is landed now.

-Yusuke

> On Aug 19, 2019, at 00:24, Yusuke Suzuki  wrote:
> 
> Hello WebKit folks!
> 
> I would like to announce that I’ve just landed the patch which introduces 
> `WTF::makeUnique` and `WTF::makeUniqueWithoutFastMallocCheck` in 
> https://trac.webkit.org/changeset/248846 
> <https://trac.webkit.org/changeset/248846>.
> They are drop-in-replacement to std::make_unique, and we should not use 
> std::make_unique after that patch is introduced.
> I’m planning to add cpplint check for `std::make_unique` to avoid the use of 
> that.
> 
> The motivation behind this change is the following.
> 
> 1. Our typical way of allocating heap memory is three-fold. Using containers 
> (Vector etc.), RefCounted, and std::unique_ptr.
> 2. Containers and RefCounted are covered well by FastMalloc.
> 3. But std::unique_ptr case, we missed using FastMalloc in many places so far.
> 
> Even in very recently written code, we missed FastMalloc annotation. For 
> example, we sometimes create a data structure just like a struct, and 
> allocate it with make_unique.
> 
> struct XXXData {
> ...
> };
> 
> m_data = std::make_unique();
> 
> We missed WTF_MAKE_STRUCT_FAST_ALLOCATED annotation in XXXData so frequently 
> so that the allocation of XXXData ends up being allocated from system-malloc.
> 
> This WTF::makeUnique adds one `static_assert` over std::make_unique: the 
> static_assert ensures T is FastMalloced or IsoHeap-allocated.
> Otherwise, we see compile-error. This mechanism surprisingly found so many 
> classes that do not have WTF_MAKE_FAST_ALLOCATED / 
> WTF_MAKE_STRUCT_FAST_ALLOCATED in our code base.
> 
> If the type T comes from ThirdParty and if we cannot annotate T with 
> FAST_ALLOCATED, we can use WTF::makeUniqueWithoutFastMallocCheck explicitly 
> as a fallback.
> 
> More detailed explanation behind why we took this design (instead of 
> allocating FastMalloced-memory automatically when using makeUnique() etc.) 
> is described in ChangeLog in https://trac.webkit.org/changeset/248846/webkit 
> <https://trac.webkit.org/changeset/248846/webkit>.
> I already annotated missed structs / classes with WTF_MAKE_FAST_ALLOCATED in 
> https://trac.webkit.org/changeset/248762 
> <https://trac.webkit.org/changeset/248762>. So, now I think 99% of 
> allocations in WebKit-itself are handled well by FastMalloc.
> 
> -Yusuke

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

[webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

[Yusuke Suzuki]

Hello WebKit folks!

I would like to announce that I’ve just landed the patch which introduces 
`WTF::makeUnique` and `WTF::makeUniqueWithoutFastMallocCheck` in 
https://trac.webkit.org/changeset/248846 
.
They are drop-in-replacement to std::make_unique, and we should not use 
std::make_unique after that patch is introduced.
I’m planning to add cpplint check for `std::make_unique` to avoid the use of 
that.

The motivation behind this change is the following.

1. Our typical way of allocating heap memory is three-fold. Using containers 
(Vector etc.), RefCounted, and std::unique_ptr.
2. Containers and RefCounted are covered well by FastMalloc.
3. But std::unique_ptr case, we missed using FastMalloc in many places so far.

Even in very recently written code, we missed FastMalloc annotation. For 
example, we sometimes create a data structure just like a struct, and allocate 
it with make_unique.

struct XXXData {
...
};

m_data = std::make_unique();

We missed WTF_MAKE_STRUCT_FAST_ALLOCATED annotation in XXXData so frequently so 
that the allocation of XXXData ends up being allocated from system-malloc.

This WTF::makeUnique adds one `static_assert` over std::make_unique: the 
static_assert ensures T is FastMalloced or IsoHeap-allocated.
Otherwise, we see compile-error. This mechanism surprisingly found so many 
classes that do not have WTF_MAKE_FAST_ALLOCATED / 
WTF_MAKE_STRUCT_FAST_ALLOCATED in our code base.

If the type T comes from ThirdParty and if we cannot annotate T with 
FAST_ALLOCATED, we can use WTF::makeUniqueWithoutFastMallocCheck explicitly as 
a fallback.

More detailed explanation behind why we took this design (instead of allocating 
FastMalloced-memory automatically when using makeUnique() etc.) is described 
in ChangeLog in https://trac.webkit.org/changeset/248846/webkit 
.
I already annotated missed structs / classes with WTF_MAKE_FAST_ALLOCATED in 
https://trac.webkit.org/changeset/248762 
. So, now I think 99% of allocations 
in WebKit-itself are handled well by FastMalloc.

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

Re: [webkit-dev] Windows 32-bit support?

[Yusuke Suzuki]

> On Jun 26, 2019, at 7:57 AM, Arunprasad Rajkumar  
> wrote:
> 
> Hi Yusuke,
> 
> I could see that the following comment from 
> https://trac.webkit.org/changeset/245906/webkit 
> <https://trac.webkit.org/changeset/245906/webkit>,
> 
> >> We also disable this op_wide16 feature in Windows CLoop, which is used in 
> >> AppleWin port. When the code size of
> >> CLoop::execute increases, MSVC starts generating CLoop::execute function 
> >> with very large stack allocation
> >> requirement. Even before introducing this 16bit bytecode, CLoop::execute 
> >> in AppleWin takes almost 100KB stack
> >> height. After introducing this, it becomes 160KB. While the semantics of 
> >> the function is correctly compiled,
> >> such a large stack allocation is not essentially necessary, and this leads 
> >> to stack overflow errors quite easily,
> >> and tests fail with AppleWin port because it starts throwing stack 
> >> overflow range error in various places.
> >> In this patch, for now, we just disable op_wide16 feature for AppleWin so 
> >> that CLoop::execute takes 100KB
> >> stack allocation because this patch is not focusing on fixing AppleWin's 
> >> CLoop issue. We introduce a new backend
> >> type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version 
> >> of code to reduce the code size of
> >> CLoop::execute. In the future, we should investigate whether this MSVC 
> >> issue is fixed in Visual Studio 2019.
> >> Or we should consider always enabling ASM LLInt for Windows.
>  
> Does that mean high stack usage in Windows is a known issue?

Yes, I think this is MSVC’s issue.
You can try using LLInt ASM for Windows if stack height problem is critical to 
you now, it would work because WinCairo is using it.
But TBH, I’m not sure whether LLInt ASM works on Win32. If the stack height 
problem is not critical, I strongly recommend using CLoop for now.

-Yusuke

> 
> Thanks & Regards,
> Arun
> 
> On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar  <mailto:ararunpra...@gmail.com>> wrote:
> Thank you all for your guidance. 
> 
> I understand that JIT and LLInt bytecode interpreter is not supported on 
> X86(32-bit). The only option I can use is C_LOOP, which have high stack usage 
> issue in the latest code. I will continue with my investigation on C_LOOP's 
> stack usage.
> 
> Thanks & Regards,
> Arun
> 
> 
> On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki  <mailto:ysuz...@apple.com>> wrote:
> 
> 
>> On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro > <mailto:ape...@igalia.com>> wrote:
>> 
>> I was mistaken about one thing (sorry!), please read below...
>> 
>> On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro 
>> mailto:ape...@igalia.com>> wrote:
>>> On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro 
>>> mailto:mcatanz...@igalia.com>> wrote:
>>>> It's great that you find our stable branches helpful, but keep in mind 
>>>> those branches do not include Windows-specific fixes.
>>>> 
>>>> On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar 
>>>> mailto:ararunpra...@gmail.com>> wrote:
>>>>> Right. Actually the problem is in 32-bit Windows platform. I see that 
>>>>> the JIT support has been dropped some time ago, and CLOOP based 
>>>>> backend seems to be unstable on 32-bit Windows. Any thoughts on that?
>>>> 
>>>> So I'm not an expert here, but I understand there are three ways you 
>>>> can build JSC:
>>>> 
>>>> (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
>>>> (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
>>>> (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
>>>> 
>>>> (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
>>>> 
>>>> I believe that nowadays the only 32-bit platforms supported by JIT are 
>>>> Linux, and there only for ARM and MIPS, not x86. So you're almost 
>>>> certainly going to need to use -DENABLE_JIT=OFF. That eliminates option 
>>>> (1).
>>> 
>>> JIT works on x86 as long as your CPU has support for SSE2 instructions.
>> 
>> Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
>> 
>> (The JIT compiler does emit SSE2 instructions, though. When/If the JIT is
>> made to work on 32-bit x86, support for SSE2 will be needed.)
> 
> WebKit no longer supports non-SSE2 x86 CPUs even without JIT.
> https://lists

Re: [webkit-dev] Windows 32-bit support?

[Yusuke Suzuki]

> On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro  wrote:
> 
> I was mistaken about one thing (sorry!), please read below...
> 
> On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro  > wrote:
>> On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro 
>>  wrote:
>>> It's great that you find our stable branches helpful, but keep in mind 
>>> those branches do not include Windows-specific fixes.
>>> 
>>> On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar 
>>>  wrote:
 Right. Actually the problem is in 32-bit Windows platform. I see that 
 the JIT support has been dropped some time ago, and CLOOP based 
 backend seems to be unstable on 32-bit Windows. Any thoughts on that?
>>> 
>>> So I'm not an expert here, but I understand there are three ways you 
>>> can build JSC:
>>> 
>>> (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
>>> (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
>>> (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
>>> 
>>> (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
>>> 
>>> I believe that nowadays the only 32-bit platforms supported by JIT are 
>>> Linux, and there only for ARM and MIPS, not x86. So you're almost 
>>> certainly going to need to use -DENABLE_JIT=OFF. That eliminates option 
>>> (1).
>> 
>> JIT works on x86 as long as your CPU has support for SSE2 instructions.
> 
> Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
> 
> (The JIT compiler does emit SSE2 instructions, though. When/If the JIT is
> made to work on 32-bit x86, support for SSE2 will be needed.)

WebKit no longer supports non-SSE2 x86 CPUs even without JIT.
https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html 


And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin) is 
recommended.

-Yusuke

> 
>>> You say the cloop seems unstable for you, which is option (3). So 
>>> perhaps you should try option (2) if you haven't already. I'm not 
>>> actually sure if that works, because I'm not an expert, which is why I 
>>> added that (?) to it. But at least it couldn't hurt to try.
>> 
>> Option (2) would be using the LLint bytecode interpreter, without JIT.
>> 
>> In principle CLoop is expected to work “everywhere” because the interpreter
>> is generated C/C++ code, which gets then built by the same compiler used to
>> build all the rest of WebKit.
>> 
>>> Maybe the Windows port maintainers know more about the status of 32-bit 
>>> Windows support?
>> 
>> Cheers,
>> —Adrián
> ___
> 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] Tadeu and Robin are now WebKit reviewers

[Yusuke Suzuki]

Congrats! :D

> On Jun 10, 2019, at 3:49 PM, Saam Barati  wrote:
> 
> Hi folks,
> 
> Tadeu and Robin are both now WebKit reviewers. Join me in congratulating 
> them. Please ask them to review your code! They both have a focus in JSC.
> 
> - Saam
> ___
> 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] C++17 is here. Should we use it?

[Yusuke Suzuki]

Cool! So,

1. We can use GCC 7
2. We can use libstdc++7

Is my understanding correct? Basically, this means that we can use cool C++17 
features super aggressively :)

Best regards,
Yusuke Suzuki

> On May 7, 2019, at 1:14 PM, Michael Catanzaro  wrote:
> 
> On Tue, May 7, 2019 at 1:46 PM, Konstantin Tokarev  wrote:
>> Note that since we have to support libstdc++ 6.x, most of C++17 standard
>> library features () should be disallowed. Those include std::filesystem,
>> std::string_view, etc. Core language features should be fine.
> 
> With my suggested one-time exception to drop support for Debian Stretch early 
> due to lack of security updates there, I think it's perfectly fine to require 
> libstdc++ 7 now. Igalia's EWS and stable release bots might need to be 
> updated, but this is not a problem.
> 
> 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] JSCOnly bots on dashboard

[Yusuke Suzuki]

On Wed, Jan 2, 2019 at 10:30 Michael Catanzaro 
wrote:

> Hi,
>
> I've updated https://build.webkit.org/dashboard/ to show our JSCOnly
> bots in addition to WPE and GTK, so we can monitor the health of these
> bots. Tip: disable all but the Linux ports in the upper-left to make
> the page load faster. Current status is:
>
>  * 90 failures on aarch64
>  * ARMv7 thumb2 and ARMv7 thumb2 softfp are GREEN! :)
>  * ARMv7 traditional fails to build
>  * 2 failures on MIPSel (one is flaky)
>
> Also:
>
>  * 1 flaky JSC test on WPE


I think this is due to the high memory pressure. Putting $memoryLimited
thing makes it work.


>  * 7-8 JSC failures on GTK


This is because of old ICU. In old ICU, Intl.NumberFormats does not work.
Intl feature usually requires very new ICU.

IIRC, the similar issue happened in test262, and Ross skipped them.
I think we should put the condition in the tests that checks the ICU
version.


>
> I promised to do this... what, half a year ago? Better late than never!
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Don Olmstead and Ross Kirsling are now WebKit reviewers

[Yusuke Suzuki]

Congrats!

On Fri, Dec 14, 2018 at 6:47 Fujii Hironori 
wrote:

> Hi everyone,
>
>
> I would like to announce that Don Olmstead (dolmstead on #webkit) and
>
> Ross Kirsling (rkirsling) are now WebKit reviewers. They have worked
>
> on WinCairo port and PlayStation port, and Ross worked on Web
>
> Inspector Layers Tab, too.
>
>
> Please join me in congratulating Don and Ross, and send them patches
>
> to review.
>
>
> Don and Ross, congratulations. 🎉
>
>
> - Fujii Hironori, Sony Interactive Entertainment Inc.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [jsc-dev] [Deadline October 30] Dropping support for Arm traditional (no Thumb2)?

[Yusuke Suzuki]

It seems nobody intends to maintain it. Let's drop it :)

On Tue, Oct 23, 2018 at 2:43 AM Guillaume Emont 
wrote:

> Hi all,
>
> With this email, I would like to express the intent of dropping support
> for Armv7 traditional (without the Thumb2 extension) from the tree.
>
> Though we at Igalia are willing to continue supporting Armv7 with Thumb2
> extension, we don't have any need for the support of platforms lacking
> Thumb2. Currently, this combination is broken and does not even compile.
> The proposed change means that going forward, the only Arm 32-bit
> architecture supported in LLInt, JIT and DFG would be Armv7 with the
> Thumb2 extension. Other variants would have to resort to using LLInt
> with the CLoop.
>
> We currently have a buildbot for Armv7 Traditional[1] and we plan to
> remove it.
>
> If anyone cares for this specific platform, and wants to step forward to
> do the maintenance work for it and set up their buildbot for it, please
> say so before October 30 (a week+ from now). Otherwise I'll assume
> nobody cares about this and I'll work on a patch to remove all the code
> we have that is specific to Arm traditional.
>
>
> Cheers,
>
> Guij
>
> [1]
> https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Traditional%20Release
> ___
> jsc-dev mailing list
> jsc-...@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/jsc-dev
>


-- 
Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] node-jsc: A node.js port to the JavaScriptCore engine and iOS

[Yusuke Suzuki]

On Sun, Sep 16, 2018 at 6:09 PM Koby Boyango  wrote:

> Thanks for taking the time to look into the project :)
>
> Filip - I would love to. Should I create one bug for all of the patches,
> or a bug for each patch?
> Also, there is an existing bug that I've reported a while ago, but worked
> around it for now: https://bugs.webkit.org/show_bug.cgi?id=184232. It
> isn't relevant in newer versions of node (it came from node's Buffer
> constructor, which have changed since), but I'll still be happy to send a
> patch if needed.
>
> Yusuke - It's interesting to compare, especially on an iOS device. I will
> also try to do some measurements :) Do you have a benchmark you recommend?
> But assuming it is worth it, enabling LLInt ASM without the JIT would be
> great as it would probably reduce the binary size and compilation time by
> quite a bit.
> NativeScript is also using it without the JIT (and they link to an article
> containing some benchmarks), so they would profit from this too.
>
> https://github.com/NativeScript/ios-runtime/commit/1528ed50f85998147b190c22a390b5eca36c5acb
>

Actually, LLInt ASM interpreter shows 15% performance win in Kraken
benchmark[1].
Based on this fact, I've just enabled LLInt ASM interpreter when using
`ENABLE_JIT=OFF` for x64 and ARM64 environments[2].

[1]:
https://lists.webkit.org/pipermail/webkit-dev/2018-September/030157.html
[2]: https://trac.webkit.org/r236381



>
>
> Koby
>
> On Sat, Sep 15, 2018 at 2:51 AM Yusuke Suzuki 
> wrote:
>
>> Really great!
>>
>> node-jsc sounds very exciting to me. From the users' view, t is nice if
>> we run app constructed in node.js manner in iOS devices.
>> In addition, from the JSC developers' view, it is also awesome. It allows
>> us to easily run node.js libraries / benchmarks / tests on JSC, which is
>> really great since,
>>
>> 1. We can run tests designed for node.js, it makes our JSC implementation
>> more solid.
>> 2. We can run benchmarks designed for node.js including JS libraries. JS
>> libraries distributed in npm are more and more used in both node.js and
>> browser world.
>> If we can have a way to run benchmarks in popular libraries on JSC
>> easily, that offers great opportunities to optimize JSC on them.
>>
>> On Sat, Sep 15, 2018 at 5:20 AM Filip Pizlo  wrote:
>>
>>> Wow!  That’s pretty cool!
>>>
>>> I think that it would be great for this to be upstreamed. Can you create
>>> a bug on bugs.webkit.org and post your patches for review?
>>>
>>> -Filip
>>>
>>> On Sep 13, 2018, at 4:02 PM, Koby Boyango  wrote:
>>>
>>> Hi,
>>>
>>> I'm Koby Boyango, a senior researcher and developer at mce, and I've
>>> created node-jsc <https://github.com/mceSystems/node-jsc>, an
>>> experimental port of node.js to the JavaScriptCore engine and iOS
>>> specifically.
>>>
>>> node-jsc's core component, "jscshim" (deps/jscshim)
>>> <https://github.com/mceSystems/node-jsc/tree/master/deps/jscshim>,
>>> implements (parts of) v8 API on top of JavaScriptCore. It contains a
>>> stripped down version of WebKit's source code (mainly JSC and WTF). To
>>> build WebKit, I'm using CMake to build the JSCOnly port, with JSC\WTF
>>> compiled as static libraries. For iOS I'm using my own build script
>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/build_jsc.py>
>>> with a custom toolchain file
>>> <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/ios.toolchain.cmake>.
>>>
>>>
>>> I'm really happy to hear that your node-jsc is using JSCOnly ports :)
>>
>>> The project also includes node-native-script
>>> <https://github.com/mceSystems/node-native-script>, NativeScript's iOS
>>> runtime refactored as node-jsc native module, allowing access to native iOS
>>> APIs directly from javascript.
>>>
>>> So first of all, I wanted to share this project with the WebKit
>>> developer community.
>>> It's my first time working with WebKit, and node-jsc has been a great
>>> opportunity to experiment with it.
>>>
>>> Second, as I needed to make some minor changes\additions, I'm using my
>>> own fork <https://github.com/mceSystems/webkit>. I would love to
>>> discuss some of the changes I've made, and offer some patches if you'll
>>> find them useful.
>>> "WebKit Fork and Compilation
>>> <https://github.

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

[Yusuke Suzuki]

Yeah, I'm not planning to enable LLInt ASM interpreter on 32bit
architectures since no buildbot exists for this configuration.
And we should make 32bit architectures JSVALUE64, so LLInt JSVALUE32_64
should be removed in the future.

On Fri, Sep 21, 2018 at 2:33 AM Michael Catanzaro 
wrote:

> On Thu, Sep 20, 2018 at 12:02 PM, Filip Pizlo  wrote:
> > - Enable cloop/JSVALUE64 to work on 32-bit.  I don’t think it does
> > right now, but that’s probably trivial to fix.
> > - Switch Darwin ports to that configuration for 32-bit.
> > - When changes land to support new features, make it mandatory to
> > support JSVALUE64 and optional to support JSVALUE32_64.  Such changes
> > should include whoever volunteers to maintain JSVALUE32_64 in CC.
> >
> > If you guys consider JSVALUE32_64 to be critical, then you can go
> > ahead and maintain it.  We’ll let JSVALUE32_64 stay in the tree so
> > long as someone is maintaining it.
>
> Yes that's fine with us. I think that's the previous agreement, anyway.
> :)
>
> Michael
>
>

-- 
Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

[Yusuke Suzuki]

I've just set up MacBook Pro to measure the effect on macOS.

The results are the followings.

VMs tested:

"baseline" at /Users/yusukesuzuki/dev/WebKit/WebKitBuild/nojit/Release/jsc

"patched" at
/Users/yusukesuzuki/dev/WebKit/WebKitBuild/nojit-llint/Release/jsc


Collected 2 samples per benchmark/VM, with 2 VM invocations per benchmark.
Emitted a call to gc() between sample

measurements. Used 1 benchmark iteration per VM invocation for warm-up.
Used the jsc-specific preciseTime()

function to get microsecond-level timing. Reporting benchmark execution
times with 95% confidence intervals in

milliseconds.


   baseline
patched


ai-astar  1738.056+-49.666 ^
1568.904+-44.535^ definitely 1.1078x faster

audio-beat-detection  1127.677+-15.749 ^
972.323+-23.908^ definitely 1.1598x faster

audio-dft  942.952+-107.209
919.933+-310.247 might be 1.0250x faster

audio-fft  985.489+-47.414 ^
796.955+-25.476^ definitely 1.2366x faster

audio-oscillator   967.891+-34.854 ^
801.778+-18.226^ definitely 1.2072x faster

imaging-darkroom  1265.340+-114.464^
1099.233+-2.372 ^ definitely 1.1511x faster

imaging-desaturate1737.826+-40.791 ?
1749.010+-167.969   ?

imaging-gaussian-blur 7846.369+-52.165 ^
6392.379+-1025.168  ^ definitely 1.2275x faster

json-parse-financial33.141+-0.473
33.054+-1.058

json-stringify-tinderbox20.803+-0.901
20.664+-0.717

stanford-crypto-aes401.589+-39.750
376.622+-12.111  might be 1.0663x faster

stanford-crypto-ccm245.629+-45.322
228.013+-8.976   might be 1.0773x faster

stanford-crypto-pbkdf2 941.178+-28.744
864.462+-60.083  might be 1.0887x faster

stanford-crypto-sha256-iterative   299.988+-47.729
270.849+-32.356  might be 1.1076x faster


  1325.281+-2.613  ^
1149.584+-75.875^ definitely 1.1528x faster

Interestingly, the improvement is not so large. In Linux box, it was 2x.
But in macOS, it is 15%.
But I think it is very nice if we can get 15% boost without any drawbacks.

On Thu, Sep 20, 2018 at 3:08 PM Saam Barati  wrote:

> Interesting! I must have not run this experiment correctly when I did it.
>
> - Saam
>
> On Sep 19, 2018, at 7:31 PM, Yusuke Suzuki 
> wrote:
>
> On Thu, Sep 20, 2018 at 12:54 AM Saam Barati  wrote:
>
>> To elaborate: I ran this same experiment before. And I forgot to turn off
>> the RegExp JIT and got results similar to what you got. Once I turned off
>> the RegExp JIT, I saw no perf difference.
>>
>
> Yeah, I disabled JIT and RegExpJIT explicitly by using
>
> export JSC_useJIT=false
> export JSC_useRegExpJIT=false
>
> and I checked no JIT code is generated by running dumpDisassembly. And I
> also put `CRASH()` in ExecutableAllocator::singleton() to ensure no
> executable memory is allocated.
> The result is the same. I think `useJIT=false` disables RegExp JIT too.
>
>baseline
> patched
>
> ai-astar  3499.046+-14.772 ^
> 1897.624+-234.517   ^ definitely 1.8439x faster
> audio-beat-detection  1803.466+-491.965
> 970.636+-428.051 might be 1.8580x faster
> audio-dft 1756.985+-68.710 ^
> 954.312+-528.406   ^ definitely 1.8411x faster
> audio-fft 1637.969+-458.129
> 850.083+-449.228 might be 1.9268x faster
> audio-oscillator  1866.006+-569.581^
> 967.194+-82.521^ definitely 1.9293x faster
> imaging-darkroom  2156.526+-591.042^
> 1231.318+-187.297   ^ definitely 1.7514x faster
> imaging-desaturate3059.335+-284.740^
> 1754.128+-339.941   ^ definitely 1.7441x faster
> imaging-gaussian-blur16034.828+-1930.938   ^
> 7389.919+-2228.020  ^ definitely 2.1698x faster
> json-parse-financial60.273+-4.143
> 53.935+-28.957  might be 1.1175x faster
> json-stringify-tinderbox39.497+-3.915
> 38.146+-9.652   might be 1.0354x faster
> stanford-crypto-aes873.623+-208.225^
> 486.350+-132.379   ^ definitely 1.7963x faster
> stanford-crypto-ccm538.707+-33.979 ^
> 285.944+-41.570^ definitely 1.8840x faster
> stanford-crypto-pbkdf21929.960+-649.861^
> 1044.320+-1.182 ^ definitely 1.8481x faster
> stanford-crypto-sha256-ite

Re: [webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

[Yusuke Suzuki]

On Thu, Sep 20, 2018 at 12:54 AM Saam Barati  wrote:

> To elaborate: I ran this same experiment before. And I forgot to turn off
> the RegExp JIT and got results similar to what you got. Once I turned off
> the RegExp JIT, I saw no perf difference.
>

Yeah, I disabled JIT and RegExpJIT explicitly by using

export JSC_useJIT=false
export JSC_useRegExpJIT=false

and I checked no JIT code is generated by running dumpDisassembly. And I
also put `CRASH()` in ExecutableAllocator::singleton() to ensure no
executable memory is allocated.
The result is the same. I think `useJIT=false` disables RegExp JIT too.

   baseline
patched

ai-astar  3499.046+-14.772 ^
1897.624+-234.517   ^ definitely 1.8439x faster
audio-beat-detection  1803.466+-491.965
970.636+-428.051 might be 1.8580x faster
audio-dft 1756.985+-68.710 ^
954.312+-528.406   ^ definitely 1.8411x faster
audio-fft 1637.969+-458.129
850.083+-449.228 might be 1.9268x faster
audio-oscillator  1866.006+-569.581^
967.194+-82.521^ definitely 1.9293x faster
imaging-darkroom  2156.526+-591.042^
1231.318+-187.297   ^ definitely 1.7514x faster
imaging-desaturate3059.335+-284.740^
1754.128+-339.941   ^ definitely 1.7441x faster
imaging-gaussian-blur16034.828+-1930.938   ^
7389.919+-2228.020  ^ definitely 2.1698x faster
json-parse-financial60.273+-4.143
53.935+-28.957  might be 1.1175x faster
json-stringify-tinderbox39.497+-3.915
38.146+-9.652   might be 1.0354x faster
stanford-crypto-aes873.623+-208.225^
486.350+-132.379   ^ definitely 1.7963x faster
stanford-crypto-ccm538.707+-33.979 ^
285.944+-41.570^ definitely 1.8840x faster
stanford-crypto-pbkdf21929.960+-649.861^
1044.320+-1.182 ^ definitely 1.8481x faster
stanford-crypto-sha256-iterative   614.344+-200.228
342.574+-123.524 might be 1.7933x faster

  2562.183+-207.456^
1304.749+-312.963   ^ definitely 1.9637x faster

I think this result is not related to RegExp JIT since ai-astar is not
using RegExp.

Best regards,
Yusuke Suzuki


>
> - Saam
>
> On Sep 19, 2018, at 8:53 AM, Saam Barati  wrote:
>
> Did you turn off the RegExp JIT?
>
> - Saam
>
> On Sep 18, 2018, at 11:23 PM, Yusuke Suzuki 
> wrote:
>
> Hi WebKittens!
>
> Recently, node-jsc is announced[1]. When I read the documents of that
> project,
> I found that they use LLInt ASM interpreter instead of CLoop in non-JIT
> environment.
> So I had one question in my mind: How fast the LLInt ASM interpreter when
> comparing to CLoop?
>
> I've set up two builds. One is CLoop build (-DENABLE_JIT=OFF) and another
> is JIT build JSC with `JSC_useJIT=false`.
> And I've ran kraken benchmarks with these two builds in x64 Linux machine.
> The results are the followings.
>
> Benchmark report for Kraken on sakura-trick.
>
> VMs tested:
> "baseline" at
> /home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit/Release/bin/jsc
> "patched" at
> /home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit-llint/Release/bin/jsc
>
> Collected 10 samples per benchmark/VM, with 10 VM invocations per
> benchmark. Emitted a call to gc() between sample
> measurements. Used 1 benchmark iteration per VM invocation for warm-up.
> Used the jsc-specific preciseTime()
> function to get microsecond-level timing. Reporting benchmark execution
> times with 95% confidence intervals in
> milliseconds.
>
>baseline
> patched
>
> ai-astar  3619.974+-57.095 ^
> 2014.835+-59.016^ definitely 1.7967x faster
> audio-beat-detection  1762.085+-24.853 ^
> 1030.902+-19.743^ definitely 1.7093x faster
> audio-dft 1822.426+-28.704 ^
> 909.262+-16.640^ definitely 2.0043x faster
> audio-fft 1651.070+-9.994  ^
> 865.203+-7.912 ^ definitely 1.9083x faster
> audio-oscillator  1853.697+-26.539 ^
> 992.406+-12.811^ definitely 1.8679x faster
> imaging-darkroom  2118.737+-23.219 ^
> 1303.729+-8.071 ^ definitely 1.6251x faster
> imaging-desaturate3133.654+-28.545 ^
> 1759.738+-18.182^ definitely 1.7808x faster
> imaging-gaussian-blur16321.090+-154.893^
> 7228.017+-58.508^ definitely 2.2580x faster
> json-parse-financial57.25

[webkit-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled

[Yusuke Suzuki]

Hi WebKittens!

Recently, node-jsc is announced[1]. When I read the documents of that
project,
I found that they use LLInt ASM interpreter instead of CLoop in non-JIT
environment.
So I had one question in my mind: How fast the LLInt ASM interpreter when
comparing to CLoop?

I've set up two builds. One is CLoop build (-DENABLE_JIT=OFF) and another
is JIT build JSC with `JSC_useJIT=false`.
And I've ran kraken benchmarks with these two builds in x64 Linux machine.
The results are the followings.

Benchmark report for Kraken on sakura-trick.

VMs tested:
"baseline" at
/home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit/Release/bin/jsc
"patched" at
/home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit-llint/Release/bin/jsc

Collected 10 samples per benchmark/VM, with 10 VM invocations per
benchmark. Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up.
Used the jsc-specific preciseTime()
function to get microsecond-level timing. Reporting benchmark execution
times with 95% confidence intervals in
milliseconds.

   baseline
patched

ai-astar  3619.974+-57.095 ^
2014.835+-59.016^ definitely 1.7967x faster
audio-beat-detection  1762.085+-24.853 ^
1030.902+-19.743^ definitely 1.7093x faster
audio-dft 1822.426+-28.704 ^
909.262+-16.640^ definitely 2.0043x faster
audio-fft 1651.070+-9.994  ^
865.203+-7.912 ^ definitely 1.9083x faster
audio-oscillator  1853.697+-26.539 ^
992.406+-12.811^ definitely 1.8679x faster
imaging-darkroom  2118.737+-23.219 ^
1303.729+-8.071 ^ definitely 1.6251x faster
imaging-desaturate3133.654+-28.545 ^
1759.738+-18.182^ definitely 1.7808x faster
imaging-gaussian-blur16321.090+-154.893^
7228.017+-58.508^ definitely 2.2580x faster
json-parse-financial57.256+-2.876
56.101+-4.265   might be 1.0206x faster
json-stringify-tinderbox38.470+-2.788  ?
38.771+-0.935 ?
stanford-crypto-aes851.341+-7.738  ^
485.438+-13.904^ definitely 1.7538x faster
stanford-crypto-ccm556.133+-6.606  ^
264.161+-3.970 ^ definitely 2.1053x faster
stanford-crypto-pbkdf21945.718+-15.968 ^
1075.013+-13.337^ definitely 1.8099x faster
stanford-crypto-sha256-iterative   623.203+-7.604  ^
349.782+-12.810^ definitely 1.7817x faster

  2596.775+-14.857 ^
1312.383+-8.840 ^ definitely 1.9787x faster

Surprisingly, LLInt ASM interpreter is significantly faster than CLoop. I
expected it would be fast, but it would show around 10% performance win.
But the reality is that it is 2x faster. It is too much number to me to
consider enabling LLInt ASM interpreter for non-JIT build configuration.
As a bonus, LLInt ASM interpreter offers sampling profiler support even in
non-JIT environment.

So my proposal is, how about enabling LLInt ASM interpreter in non-JIT
configuration environment in major architectures (x64 and ARM64)?

Best regards,
Yusuke Suzuki

[1]:
https://lists.webkit.org/pipermail/webkit-dev/2018-September/030140.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] node-jsc: A node.js port to the JavaScriptCore engine and iOS

[Yusuke Suzuki]

Really great!

node-jsc sounds very exciting to me. From the users' view, t is nice if we
run app constructed in node.js manner in iOS devices.
In addition, from the JSC developers' view, it is also awesome. It allows
us to easily run node.js libraries / benchmarks / tests on JSC, which is
really great since,

1. We can run tests designed for node.js, it makes our JSC implementation
more solid.
2. We can run benchmarks designed for node.js including JS libraries. JS
libraries distributed in npm are more and more used in both node.js and
browser world.
If we can have a way to run benchmarks in popular libraries on JSC easily,
that offers great opportunities to optimize JSC on them.

On Sat, Sep 15, 2018 at 5:20 AM Filip Pizlo  wrote:

> Wow!  That’s pretty cool!
>
> I think that it would be great for this to be upstreamed. Can you create a
> bug on bugs.webkit.org and post your patches for review?
>
> -Filip
>
> On Sep 13, 2018, at 4:02 PM, Koby Boyango  wrote:
>
> Hi,
>
> I'm Koby Boyango, a senior researcher and developer at mce, and I've
> created node-jsc , an
> experimental port of node.js to the JavaScriptCore engine and iOS
> specifically.
>
> node-jsc's core component, "jscshim" (deps/jscshim)
> ,
> implements (parts of) v8 API on top of JavaScriptCore. It contains a
> stripped down version of WebKit's source code (mainly JSC and WTF). To
> build WebKit, I'm using CMake to build the JSCOnly port, with JSC\WTF
> compiled as static libraries. For iOS I'm using my own build script
> 
> with a custom toolchain file
> .
>
>
> I'm really happy to hear that your node-jsc is using JSCOnly ports :)

> The project also includes node-native-script
> , NativeScript's iOS
> runtime refactored as node-jsc native module, allowing access to native iOS
> APIs directly from javascript.
>
> So first of all, I wanted to share this project with the WebKit developer
> community.
> It's my first time working with WebKit, and node-jsc has been a great
> opportunity to experiment with it.
>
> Second, as I needed to make some minor changes\additions, I'm using my
> own fork . I would love to discuss
> some of the changes I've made, and offer some patches if you'll find them
> useful.
> "WebKit Fork and Compilation
> "
> describes WebKit's usage in node-jsc and the major changes\additions I've
> made in my fork (node-jsc's README
>  and jschim's
> documentation
> 
> contains some more information).
>
> Great, it is really nice if you have a patch for upstream :)
Looking through the documents, I have one question on LLInt v.s. CLoop.

https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit_fork_and_compilation.md#webkit-port-and-compilation
> Use the optimized assembly version of LLInt (JSC's interpreter), not
cloop. This requires enabling JIT support, although we won't be using the
JIT (but we can omit the FTL jit).

I would like to know how fast LLInt ASM interpreter is when comparing CLoop
interpreter.
If it shows nice speedup, enabling LLInt ASM interpreter without JIT for
major architectures (x64, ARM64) sounds nice.
As a bonus, if we offer this build configuration (using LLInt ASM
interpreter without JIT), we can enable SamplingProfiler for this, which is
disabled for CLoop builds.

Personally, I'm also interested in this thing. I'll set up the environment
to measure it later too :)


> Besides that, I will appreciate any opinions\ideas\insights\suggestions :)
>
>





> Koby
>
> ___
> 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] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 4:10 Filip Pizlo  wrote:

>
> On Aug 28, 2018, at 12:09 PM, Yusuke Suzuki 
> wrote:
>
>
>
> On Wed, Aug 29, 2018 at 3:58 Filip Pizlo  wrote:
>
>>
>> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki 
>> wrote:
>>
>>
>>
>> On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:
>>>
>>>>
>>>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
>>>> wrote:
>>>>
>>>> Thanks!
>>>>
>>>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  wrote:
>>>>
>>>>> I don’t like this proposal.
>>>>>
>>>>> If we are running low on memory, we should switch to bounds checked
>>>>> memory.
>>>>>
>>>>
>>>> How about using bound checking mode exclusively for low environment?
>>>>
>>>>
>>>> That would mean that, paradoxically, having a machine with a lot of
>>>> memory means being able to spawn fewer wasm instances.
>>>>
>>>> We want to support lightweight wasm instances because it wouldn’t be
>>>> good to rule that out as a use case.
>>>>
>>>
>>> Hmmm, can we compile the BBQ phase / initial wasm code without knowing
>>> the attached memory’s mode? The current strategy basically defers
>>> compilation of wasm module until the memory mode is found.
>>> Because of this, WebAssembly.compile is not so meaningful in our
>>> implementation right now...
>>> And wasm ES6 module can import memory externally. This means that we
>>> cannot start wasm compilation after the memory mode of the impprted memory
>>> (described in the imported modulr) is downloaded, analyzed and found.
>>>
>>
>> How about always compiling BBQ code with bound checking mode?
>> It should work with signaling memory with small / no tweaks. And OMG code
>> will be compiled based on the memory mode attached to the module.
>> Since BBQ -> OMG function call should be linked, we need to call
>> appropriate func for the running memory mode, but it would not introduce
>> significant complexity.
>>
>>
>> What complexity are you trying to fix, specifically?
>>
>
> What I want is starting compilation before the memory is attached a.k.a.
> instantiated)
>
>
>> I think that what we really want is an interpreter as our baseline.  Then
>> tier-up to BBQ or OMG from there.  In that world, I don’t think any of this
>> matters.
>>
>
> Does this interpreter execute wasm binary directly? If so, we can skip
> compiling and all should work well!
>
> Even if we want some own bytecode (like stack VM to register VM etc.), it
> is ok if the compilation result is not tied to the memory mode.
>
>
> I don’t know if it will execute the wasm binary directly, but whatever
> bytecode it runs could be dissociated from memory mode.
>

Thanks, that sounds reasonable!
If the bytecode compilation etc. is disassociated from the memory mode, the
bytecode can be compiled before instantiated. It means that wasm module can
be shared between workers (like postMessage the wasm module having compiled
bytecode). And we can start compiling before the memory is attached
(instantiated).



> -Filip
>
>
>
> If the compilation result is tied to the memory mode, then we still need
> to defer the compilation until the memory mode is attached.
>
>>
>
>> -Filip
>>
>>
>>
>>
>>
>>>
>>>> -Filip
>>>>
>>>>
>>>>
>>>>
>>>>> -Filip
>>>>>
>>>>>
>>>>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki <
>>>>> yusukesuz...@slowstart.org> wrote:
>>>>>
>>>>> Posted this mail to webkit-dev mailing list too :)
>>>>>
>>>>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki <
>>>>> yusukesuz...@slowstart.org> wrote:
>>>>>
>>>>>> Hi JSC folks,
>>>>>>
>>>>>> In Wasm supported environment, our MemoryMode is a bit dynamic.
>>>>>> When we fail to allocate WasmMemory for signaling mode, we fall back
>>>>>> to the bound checking memory instead.
>>>>>>
>>>>>> But Wasm code compiled for signaling / bound checking is
>>>>>> incompatible. If the code is compiled
>

Re: [webkit-dev] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 3:58 Filip Pizlo  wrote:

>
> On Aug 28, 2018, at 11:56 AM, Yusuke Suzuki 
> wrote:
>
>
>
> On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki 
> wrote:
>
>>
>>
>> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:
>>
>>>
>>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
>>> wrote:
>>>
>>> Thanks!
>>>
>>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  wrote:
>>>
>>>> I don’t like this proposal.
>>>>
>>>> If we are running low on memory, we should switch to bounds checked
>>>> memory.
>>>>
>>>
>>> How about using bound checking mode exclusively for low environment?
>>>
>>>
>>> That would mean that, paradoxically, having a machine with a lot of
>>> memory means being able to spawn fewer wasm instances.
>>>
>>> We want to support lightweight wasm instances because it wouldn’t be
>>> good to rule that out as a use case.
>>>
>>
>> Hmmm, can we compile the BBQ phase / initial wasm code without knowing
>> the attached memory’s mode? The current strategy basically defers
>> compilation of wasm module until the memory mode is found.
>> Because of this, WebAssembly.compile is not so meaningful in our
>> implementation right now...
>> And wasm ES6 module can import memory externally. This means that we
>> cannot start wasm compilation after the memory mode of the impprted memory
>> (described in the imported modulr) is downloaded, analyzed and found.
>>
>
> How about always compiling BBQ code with bound checking mode?
> It should work with signaling memory with small / no tweaks. And OMG code
> will be compiled based on the memory mode attached to the module.
> Since BBQ -> OMG function call should be linked, we need to call
> appropriate func for the running memory mode, but it would not introduce
> significant complexity.
>
>
> What complexity are you trying to fix, specifically?
>

What I want is starting compilation before the memory is attached a.k.a.
instantiated)


> I think that what we really want is an interpreter as our baseline.  Then
> tier-up to BBQ or OMG from there.  In that world, I don’t think any of this
> matters.
>

Does this interpreter execute wasm binary directly? If so, we can skip
compiling and all should work well!

Even if we want some own bytecode (like stack VM to register VM etc.), it
is ok if the compilation result is not tied to the memory mode.

If the compilation result is tied to the memory mode, then we still need to
defer the compilation until the memory mode is attached.

>

> -Filip
>
>
>
>
>
>>
>>> -Filip
>>>
>>>
>>>
>>>
>>>> -Filip
>>>>
>>>>
>>>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki 
>>>> wrote:
>>>>
>>>> Posted this mail to webkit-dev mailing list too :)
>>>>
>>>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki <
>>>> yusukesuz...@slowstart.org> wrote:
>>>>
>>>>> Hi JSC folks,
>>>>>
>>>>> In Wasm supported environment, our MemoryMode is a bit dynamic.
>>>>> When we fail to allocate WasmMemory for signaling mode, we fall back
>>>>> to the bound checking memory instead.
>>>>>
>>>>> But Wasm code compiled for signaling / bound checking is incompatible.
>>>>> If the code is compiled
>>>>> as signaling mode, and if we attach the memory for bound checking, we
>>>>> need to recompile the
>>>>> code for bound checking mode. This introduces significant complexity
>>>>> to our wasm compilation.
>>>>> And our WebAssembly.compile is not basically compiling: it is just
>>>>> validating.
>>>>> Actual compiling needs to be deferred until the memory is attached by
>>>>> instantiating.
>>>>> It is not good when we would like to share WasmModule among multiple
>>>>> wasm threads / workers in the future, since the "compiled" Wasm module is
>>>>> not actually compiled.
>>>>>
>>>>> So, my proposal is, can we explore the way to exclusively support one
>>>>> of MemoryMode in a certain architecture?
>>>>> For example, in x64, enable signaling mode, and we report OOM errors
>>>>> if we fail to allocate WasmMemory with signaling mode.
>>>>>
>>>>> 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] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 3:49 Yusuke Suzuki 
wrote:

>
>
> On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:
>
>>
>> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
>> wrote:
>>
>> Thanks!
>>
>> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  wrote:
>>
>>> I don’t like this proposal.
>>>
>>> If we are running low on memory, we should switch to bounds checked
>>> memory.
>>>
>>
>> How about using bound checking mode exclusively for low environment?
>>
>>
>> That would mean that, paradoxically, having a machine with a lot of
>> memory means being able to spawn fewer wasm instances.
>>
>> We want to support lightweight wasm instances because it wouldn’t be good
>> to rule that out as a use case.
>>
>
> Hmmm, can we compile the BBQ phase / initial wasm code without knowing the
> attached memory’s mode? The current strategy basically defers compilation
> of wasm module until the memory mode is found.
> Because of this, WebAssembly.compile is not so meaningful in our
> implementation right now...
> And wasm ES6 module can import memory externally. This means that we
> cannot start wasm compilation after the memory mode of the impprted memory
> (described in the imported modulr) is downloaded, analyzed and found.
>

How about always compiling BBQ code with bound checking mode?
It should work with signaling memory with small / no tweaks. And OMG code
will be compiled based on the memory mode attached to the module.
Since BBQ -> OMG function call should be linked, we need to call
appropriate func for the running memory mode, but it would not introduce
significant complexity.



>
>> -Filip
>>
>>
>>
>>
>>> -Filip
>>>
>>>
>>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki 
>>> wrote:
>>>
>>> Posted this mail to webkit-dev mailing list too :)
>>>
>>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki <
>>> yusukesuz...@slowstart.org> wrote:
>>>
>>>> Hi JSC folks,
>>>>
>>>> In Wasm supported environment, our MemoryMode is a bit dynamic.
>>>> When we fail to allocate WasmMemory for signaling mode, we fall back to
>>>> the bound checking memory instead.
>>>>
>>>> But Wasm code compiled for signaling / bound checking is incompatible.
>>>> If the code is compiled
>>>> as signaling mode, and if we attach the memory for bound checking, we
>>>> need to recompile the
>>>> code for bound checking mode. This introduces significant complexity to
>>>> our wasm compilation.
>>>> And our WebAssembly.compile is not basically compiling: it is just
>>>> validating.
>>>> Actual compiling needs to be deferred until the memory is attached by
>>>> instantiating.
>>>> It is not good when we would like to share WasmModule among multiple
>>>> wasm threads / workers in the future, since the "compiled" Wasm module is
>>>> not actually compiled.
>>>>
>>>> So, my proposal is, can we explore the way to exclusively support one
>>>> of MemoryMode in a certain architecture?
>>>> For example, in x64, enable signaling mode, and we report OOM errors if
>>>> we fail to allocate WasmMemory with signaling mode.
>>>>
>>>> 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] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

On Wed, Aug 29, 2018 at 3:27 Filip Pizlo  wrote:

>
> On Aug 28, 2018, at 11:25 AM, Yusuke Suzuki 
> wrote:
>
> Thanks!
>
> On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  wrote:
>
>> I don’t like this proposal.
>>
>> If we are running low on memory, we should switch to bounds checked
>> memory.
>>
>
> How about using bound checking mode exclusively for low environment?
>
>
> That would mean that, paradoxically, having a machine with a lot of memory
> means being able to spawn fewer wasm instances.
>
> We want to support lightweight wasm instances because it wouldn’t be good
> to rule that out as a use case.
>

Hmmm, can we compile the BBQ phase / initial wasm code without knowing the
attached memory’s mode? The current strategy basically defers compilation
of wasm module until the memory mode is found.
Because of this, WebAssembly.compile is not so meaningful in our
implementation right now...
And wasm ES6 module can import memory externally. This means that we cannot
start wasm compilation after the memory mode of the impprted memory
(described in the imported modulr) is downloaded, analyzed and found.


> -Filip
>
>
>
>
>> -Filip
>>
>>
>> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki 
>> wrote:
>>
>> Posted this mail to webkit-dev mailing list too :)
>>
>> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki 
>> wrote:
>>
>>> Hi JSC folks,
>>>
>>> In Wasm supported environment, our MemoryMode is a bit dynamic.
>>> When we fail to allocate WasmMemory for signaling mode, we fall back to
>>> the bound checking memory instead.
>>>
>>> But Wasm code compiled for signaling / bound checking is incompatible.
>>> If the code is compiled
>>> as signaling mode, and if we attach the memory for bound checking, we
>>> need to recompile the
>>> code for bound checking mode. This introduces significant complexity to
>>> our wasm compilation.
>>> And our WebAssembly.compile is not basically compiling: it is just
>>> validating.
>>> Actual compiling needs to be deferred until the memory is attached by
>>> instantiating.
>>> It is not good when we would like to share WasmModule among multiple
>>> wasm threads / workers in the future, since the "compiled" Wasm module is
>>> not actually compiled.
>>>
>>> So, my proposal is, can we explore the way to exclusively support one of
>>> MemoryMode in a certain architecture?
>>> For example, in x64, enable signaling mode, and we report OOM errors if
>>> we fail to allocate WasmMemory with signaling mode.
>>>
>>> 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] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

Thanks!

On Wed, Aug 29, 2018 at 3:22 Filip Pizlo  wrote:

> I don’t like this proposal.
>
> If we are running low on memory, we should switch to bounds checked memory.
>

How about using bound checking mode exclusively for low environment?


> -Filip
>
>
> On Aug 28, 2018, at 11:21 AM, Yusuke Suzuki 
> wrote:
>
> Posted this mail to webkit-dev mailing list too :)
>
> On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki 
> wrote:
>
>> Hi JSC folks,
>>
>> In Wasm supported environment, our MemoryMode is a bit dynamic.
>> When we fail to allocate WasmMemory for signaling mode, we fall back to
>> the bound checking memory instead.
>>
>> But Wasm code compiled for signaling / bound checking is incompatible. If
>> the code is compiled
>> as signaling mode, and if we attach the memory for bound checking, we
>> need to recompile the
>> code for bound checking mode. This introduces significant complexity to
>> our wasm compilation.
>> And our WebAssembly.compile is not basically compiling: it is just
>> validating.
>> Actual compiling needs to be deferred until the memory is attached by
>> instantiating.
>> It is not good when we would like to share WasmModule among multiple wasm
>> threads / workers in the future, since the "compiled" Wasm module is not
>> actually compiled.
>>
>> So, my proposal is, can we explore the way to exclusively support one of
>> MemoryMode in a certain architecture?
>> For example, in x64, enable signaling mode, and we report OOM errors if
>> we fail to allocate WasmMemory with signaling mode.
>>
>> 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] Can we drop supporting mixed Wasm::MemoryMode in one process?

[Yusuke Suzuki]

Posted this mail to webkit-dev mailing list too :)

On Wed, Aug 29, 2018 at 3:19 AM Yusuke Suzuki 
wrote:

> Hi JSC folks,
>
> In Wasm supported environment, our MemoryMode is a bit dynamic.
> When we fail to allocate WasmMemory for signaling mode, we fall back to
> the bound checking memory instead.
>
> But Wasm code compiled for signaling / bound checking is incompatible. If
> the code is compiled
> as signaling mode, and if we attach the memory for bound checking, we need
> to recompile the
> code for bound checking mode. This introduces significant complexity to
> our wasm compilation.
> And our WebAssembly.compile is not basically compiling: it is just
> validating.
> Actual compiling needs to be deferred until the memory is attached by
> instantiating.
> It is not good when we would like to share WasmModule among multiple wasm
> threads / workers in the future, since the "compiled" Wasm module is not
> actually compiled.
>
> So, my proposal is, can we explore the way to exclusively support one of
> MemoryMode in a certain architecture?
> For example, in x64, enable signaling mode, and we report OOM errors if we
> fail to allocate WasmMemory with signaling mode.
>
> Best regards,
> Yusuke Suzuki
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Not supporting x86 w/o SSE2

[Yusuke SUZUKI]

On Mon, Jul 30, 2018 at 4:37 AM Darin Adler  wrote:

> Sounds good.
>
> There are clients of WebKit outside web browsing. A significant client
> like that on Windows at Apple is iTunes. I checked <
> https://www.apple.com/itunes/download/> and Windows versions of iTunes
> require a processor with support for SSE2, so clarifying WebKit’s lack of
> support won’t be a problem there.
>

That's cool!
I also want to note that Windows 7 seems dropping non-SSE2 x86 support[1]

> Symptom
> A Stop error occurs on computers that don't support Streaming Single
Instructions Multiple Data (SIMD) Extensions 2 (SSE2).
> Workaround
> Upgrade your machines with a processor that supports SSE2 or virtualize
those machines.

[1]:
https://support.microsoft.com/en-us/help/4088875/windows-7-update-kb4088875



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

[webkit-dev] Proposal: Not supporting x86 w/o SSE2

[Yusuke SUZUKI]

Hello WebKittens,

To mitigate recent side-channel attacks, we added `lfence` in x86 WebKit.
But this is supported in x86 SSE2. So the ToT WebKit is not usable with
very old x86 CPUs which do not have SSE2[1].

According to [2], Mozilla Firefox 49 no longer supports x86 w/o SSE2.
Since Firefox 45 ESR is already End of Life, all the supported Firefox
require SSE2 on x86.
Chromium also does not support x86 if it does not have SSE2 IIRC[3].
So, no major browsers support x86 w/o SSE2 right now.

I think our stakeholders do not maintain non-SSE2 x86.
Even if it works, it is potentially vulnerable, and I think it is not
acceptable for the browser engine.

My proposal here is clarifying that WebKit does not support x86 not having
SSE2.

[1]: https://bugs.webkit.org/show_bug.cgi?id=188145
[2]: https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763290
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Fujii Hironori is now a WebKit reviewer

[Yusuke SUZUKI]

Congrats!

On Sun, Jul 15, 2018 at 2:30 Michael Catanzaro 
wrote:

> Hi,
>
> Fujii Hironori is now a WebKit reviewer. He has expertise in Windows
> support, WebKitGTK+, and WebCore bugs. Please congratulate him and send
> him patches to review!
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
Regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JavaScriptCore on Fuchsia

[Yusuke SUZUKI]

Sounds very cool!

On Wed, Jun 27, 2018 at 6:01 AM Adam Barth  wrote:

> As part of developing Fuchsia [1] (a new open-source operating
> system), we ported JavaScriptCore to run on Fuchsia [2].  At the time,
> our intent was to use this code within the Fuchsia source tree but not
> to make it available for developers writing applications for Fuchsia.
> However, recently, we've gotten a number of requests from customers
> who would like to use JavaScriptCore in their Fuchsia applications.
>
> I'd like your advice about the best way to maintain JavaScriptCore
> support for Fuchsia.  Here are some possibilities I can imagine, but
> we're open to other possibilities as well:
>
> 1. Maintain a fork of JavaScriptCore somewhere on googlesource.com
> that supports Fuchsia and instruct customers to obtain the Fuchsia
> port of JavaScriptCore from googlesource.com.
>
> 2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports
> Fuchsia.
>
> 3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org.
>
> For reference, here's the patch we applied to WTF and JavaScriptCore
> to enable Fuchsia support:
>
> https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96


We are working on making JSC portable by introducing JSCOnly[1], so given
very small changes for Fushcia are super exciting (positive) results to me!

Looking through the patch in the gist, the ToT JSC moves
MachineStackMarker.cpp's
platform dependent part to WTF to make JSC further platform-independent.
So I think changes in JSC are further small: the required work for Fushcia
port is
mainly extending WTF for Fushcia OS.

My suggestion is introducing Fushcia port, adding both PLATFORM(FUSHCIA)
and OS(FUSHCIA) ifdefs.
Use OS(FUSHCIA) when the change is b/c of Fushcia's APIs. And use
PLATFORM(FUSHCIA) to change
the policy of the released build (e.g. enabling / disabling FTL JIT etc.).
By doing so, JSCOnly port also becomes available in Fushcia. And it means
that Fushcia port can benefit
from JSCOnly port's work for making WTF and JSC portable.

[1]: https://lists.webkit.org/pipermail/webkit-dev/2015-November/027785.html

>
>
> This patch is based on webkit@206446, but we'd obviously rebase the
> patch onto top-of-tree before contributing it.
>
> I'm happy to answer any questions you might have that would help you
> provide the best advice.  If you would prefer to communicate off-list,
> I'm happy to do that as well.
>
> Thanks in advance,
> Adam
>
> [1] https://fuchsia.googlesource.com/docs/+/master/README.md
> [2] Actually, if you look at
> https://fuchsia.googlesource.com/third_party/webkit, you'll see that
> we've ported WebCore as well, but this email concerns only
> JavaScriptCore.
> ___
> 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] [jsc-dev] Proposal: Removing ENABLE(INTL)

[Yusuke SUZUKI]

Thanks all!

OK, so ICU 54 is enough for ENABLE(INTL) and all of our supporting
environment just has ICU 54.
I'll open a bug for removing ENABLE(INTL) :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for upgrading xcode toolchains in Apple bots for C++17

[Yusuke SUZUKI]

Thanks,

On Tue, May 22, 2018 at 1:30 AM Alexey Proskuryakov  wrote:

> Hi,
>
> To clarify, are you asking specifically for mac-32bit EWS to be upgraded?
>

No, I'm asking for upgrading mac/ios bots except for mac-32bit.


> It has Xcode 9.2, and can be upgraded to 9.3.1 (that will be a multi-step
> process, as we need to keep the version in sync with several other setups).
> But macOS Sierra bots have Xcode 8.3.3, and that is the latest release for
> Sierra.
>

Oh! Hmm, OK. So, to avoid build failures, we need to have the way to
distinguish these 8.3.3's clang from 9.2 - 9.3.1 clangs.
In terms of the implementation status of C++17, it is not a problem. Even
clang 4 shows good status compared to GCC 6.


>
> - Alexey
>
>
> 21 мая 2018 г., в 6:44, Yusuke SUZUKI  написал(а):
>
> Hi WebKittens, in particular Apple bot maintainers!
>
> We are about to enable C++17 in all the WebKit ports, and the last step is
> enabling C++17 for Xcode[1].
> While the latest shipped Xcode (w/ clang) supports C++17 option
> (`-std=gnu++17`), EWS build bots do not support this. Some build bots
> accept `-std=c++1z`, this option causes trouble in the latest Xcode (e.g.
> mac-32bit uses the newer Xcode).
>
> Can we upgrade Xcodes in EWS and buildbots to the latest ones to accept
> C++17 option? Once it is done, WebKit starts using fancy C++17 features
> listed in GCC 6.0.
>
> Best regards,
> Yusuke Suzuki
>
> [1]: https://bugs.webkit.org/show_bug.cgi?id=185176
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> - Alexey
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for upgrading xcode toolchains in Apple bots for C++17

[Yusuke SUZUKI]

Hi WebKittens, in particular Apple bot maintainers!

We are about to enable C++17 in all the WebKit ports, and the last step is
enabling C++17 for Xcode[1].
While the latest shipped Xcode (w/ clang) supports C++17 option
(`-std=gnu++17`), EWS build bots do not support this. Some build bots
accept `-std=c++1z`, this option causes trouble in the latest Xcode (e.g.
mac-32bit uses the newer Xcode).

Can we upgrade Xcodes in EWS and buildbots to the latest ones to accept
C++17 option? Once it is done, WebKit starts using fancy C++17 features
listed in GCC 6.0.

Best regards,
Yusuke Suzuki

[1]: https://bugs.webkit.org/show_bug.cgi?id=185176
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Proposal: Removing ENABLE(INTL)

[Yusuke SUZUKI]

Hi WebKittens,

I would like to remove ENABLE(INTL) compile time flag and always enable
INTL.
This is ECMAScript Intl (i18n) feature. This feature depends on ICU.
But right now, even JSC (and WTF) always require ICU. Even if we disable
ENABLE(INTL), we still require ICU.

New INTL features are gurded separately with the compile flags (since some
new features require new ICU). So, removing ENABLE(INTL) just enables Intl
basic features, which are shipped more than 1 year ago and it is quite
mature.

Best regards,
Yusuke Suzuki
-- 
Regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [jsc-dev] Question about ARMv7 JIT maintenance by Apple

[Yusuke SUZUKI]

On Wed, May 9, 2018 at 6:46 AM Michael Saboff  wrote:

> Yusuke,
>
> What are the deficiencies you see in the current ARMv7 disassembler?
>

This is just removing some code in WebKit tree. Basically there is no
functionality difference.
Currently, MIPS and ARM use capstone disassembler. If we can use this for
ARMv7, it simplifies the implementation.

I don't want to use capstone for X86, X86_64, and ARM64 right now since
these instruction sets are really changing: new instructions are added
frequently.
So I would like to have our own ones in the tree. But for MIPS, ARM and
ARMv7, instruction sets are not so changed in terms of our JIT.

Best regards,
Yusuke Suzuki


>
> - Michael
>
> On May 4, 2018, at 7:45 PM, Yusuke SUZUKI  wrote:
>
> On Sat, May 5, 2018 at 11:27 AM Filip Pizlo  wrote:
>
>> We aren’t maintaining armv7.
>>
>
> OK, thanks. I'll replace ARMv7 disassembler with capstone based one once
> capstone is adopted :)
>
>
>
>>
>> -Filip
>>
>> > On May 4, 2018, at 7:01 PM, Yusuke SUZUKI 
>> wrote:
>> >
>> > Hi WebKittens,
>> >
>> > JSC has X86, X86_64, ARM64, ARM, ARMv7, and MIPS JIT architectures.
>> > While X86, X86_64, and ARM64 is maintained by build bots configured by
>> Apple,
>> > the other architectures are maintained by the community.
>> >
>> > Recently, I'm about to adopting capstone disassembler for MIPS and ARM.
>> > And I'm also wondering if ARMv7 can use it instead of our own
>> disassembler.
>> >
>> > So my question is, is ARMv7 JIT maintained by Apple right now? Or is it
>> maintained by the community?
>> > If Apple does not maintain it right now, I would like to drop ARMv7
>> disassembler and use capstone instead.
>> >
>> > Best regards,
>> > Yusuke Suzuki
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
> ___
> jsc-dev mailing list
> jsc-...@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/jsc-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Question about ARMv7 JIT maintenance by Apple

[Yusuke SUZUKI]

On Sat, May 5, 2018 at 11:27 AM Filip Pizlo  wrote:

> We aren’t maintaining armv7.
>

OK, thanks. I'll replace ARMv7 disassembler with capstone based one once
capstone is adopted :)



>
> -Filip
>
> > On May 4, 2018, at 7:01 PM, Yusuke SUZUKI  wrote:
> >
> > Hi WebKittens,
> >
> > JSC has X86, X86_64, ARM64, ARM, ARMv7, and MIPS JIT architectures.
> > While X86, X86_64, and ARM64 is maintained by build bots configured by
> Apple,
> > the other architectures are maintained by the community.
> >
> > Recently, I'm about to adopting capstone disassembler for MIPS and ARM.
> > And I'm also wondering if ARMv7 can use it instead of our own
> disassembler.
> >
> > So my question is, is ARMv7 JIT maintained by Apple right now? Or is it
> maintained by the community?
> > If Apple does not maintain it right now, I would like to drop ARMv7
> disassembler and use capstone instead.
> >
> > 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] Question about ARMv7 JIT maintenance by Apple

[Yusuke SUZUKI]

Hi WebKittens,

JSC has X86, X86_64, ARM64, ARM, ARMv7, and MIPS JIT architectures.
While X86, X86_64, and ARM64 is maintained by build bots configured by
Apple,
the other architectures are maintained by the community.

Recently, I'm about to adopting capstone disassembler for MIPS and ARM.
And I'm also wondering if ARMv7 can use it instead of our own disassembler.

So my question is, is ARMv7 JIT maintained by Apple right now? Or is it
maintained by the community?
If Apple does not maintain it right now, I would like to drop ARMv7
disassembler and use capstone instead.

Best regards,
Yusuke Suzuki
___
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

[Yusuke SUZUKI]

Thanks, it sounds reasonable :)

On Tue, May 1, 2018 at 1:47 Geoffrey Garen  wrote:

> 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

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

[Yusuke SUZUKI]

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] Not adding DFG 32bit specialized code as much as possible!

[Yusuke SUZUKI]

Hi, WebKittens, in particular, JSC folks,

Recently I largely removed duplicate 32bit DFG code by unifying the
implementation of 32bit and 64bit. Initially, we have separate code for
32bit and 64bit. But as our DFG infrastructure grows, we have fancy DFG
features that enables writing unified implementation for 32bit and 64bit.
For example, JSValueRegs families offer the way to handle JSValue registers
transparently.

Unifying the code significantly reduces the size of
DFGSpeculativeJIT32_64.cpp. It reduces maintenance burden. In addition, it
finds bugs, for example, 32bit code sometimes lacks the changes done in
64bit code (e.g. mutatorFence). This unification finds and fixes such a bug.

So I suggest not adding code to DFGSpeculativeJIT32_64.cpp as much as
possible. We can implement large part of DFG code in 32/64 unified code
with our infrastructure. If your 32bit code is slightly different from
64bit code, I believe adding ifdef in DFGSpeculativeJIT.cpp is rather fine.
It highlights what our infrastructure is missing to implement it in unified
code. And later, such ifdefs will be removed.

Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Be careful for using `new builtin[xxx]` / `make_unique(num)`

[Yusuke SUZUKI]

Hi WebKittens,

I recently saw several `make_unique(num)` code.
This is good if we know that we do not extend this array dynamically.
However, be careful for the type of this... Otherwise, we bypass bmalloc
and go to slow system malloc!
For example, `make_unique(num)` will allocate buffer from system
malloc.

If you use `std::make_unique(num)` and XXX uses
WTF_MAKE_FAST_ALLOCATED, it is OK since it has new[]/delete[] operators.

I think one way to alleviate this issue is just using MallocPtr.
Personally, I would like to use make_unique, but it does not accept
allocator for std::unique_ptr's XXX.

Please correct me if I'm wrong.

Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Test262 includes some tab characters

[Yusuke SUZUKI]

On Mon, Feb 5, 2018 at 5:24 AM, Alexey Proskuryakov  wrote:

>
> > 4 февр. 2018 г., в 7:09, Yusuke SUZUKI 
> написал(а):
> >
> > Hi WebKittens,
> >
> > Recently, I updated test262, and I found newly added test262 files
> include TAB characters (\t).
> > IIRC, I need some help to import such files into WebKit tree.
> > Can we make JSTests/test262 directory free from any SVN style checks?
>
> Yes, one can add an allow-tabs property to bypass the check in pre-commit
> hook. This can be part of the patch.
>

Thank you, that's nice.
Maybe, I need to create a patch on SVN instead of git-svn.


> - Alexey
>
> > 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] Test262 includes some tab characters

[Yusuke SUZUKI]

Hi WebKittens,

Recently, I updated test262, and I found newly added test262 files include
TAB characters (\t).
IIRC, I need some help to import such files into WebKit tree.
Can we make JSTests/test262 directory free from any SVN style checks?

Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Meltdown and Spectre attacks

[Yusuke SUZUKI]

FYI, Apple also published the statement.

https://support.apple.com/en-us/HT208394

On Sat, Jan 6, 2018 at 1:08 Michael Catanzaro  wrote:

> Hi,
>
> Here's a collection of blog posts from other major browser vendors
> regarding the Meltdown and Spectre attacks:
>
>
> https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/
>
>
> https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
>
> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
>
> Notably, Edge and Firefox are reducing the resolution of
> performance.now(), and all three are disabling SharedArrayBuffer.
>
> This is just a heads-up.
>
> Michael
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
Regards,
Yusuke Suzuki
___
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

[Yusuke SUZUKI]

Thank you for your replies!

On Wed, Dec 6, 2017 at 8:48 AM, Olmstead, Don  wrote:

> We’re fine with removing it.
>

That's nice!


>
>
> *From:* webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] *On
> Behalf Of *Geoffrey Garen
> *Sent:* Tuesday, December 5, 2017 2:35 PM
> *To:* Michael Saboff 
> *Cc:* John N. Lehner ; WebKit-Dev <
> webkit-dev@lists.webkit.org>
> *Subject:* Re: [webkit-dev] Proposal: Do not support Windows fibers
>
>
>
> 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
>

Yeah, I think we should assume that WebKit is not supporting Windows fibers.


>
>
> 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
>
>
Nice. So Windows fiber is not used :)



>
>
> 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.
>
>
Yeah. At least, I think the platform provided fibers are not encouraged in
WebKit.


>
> - 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Proposal: Do not support Windows fibers

[Yusuke SUZUKI]

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

Re: [webkit-dev] Heads up: Handling many minor CPUs as CPU(UNKNOWN)

[Yusuke SUZUKI]

FYI, explicitly supported CPUs are, X86, X86_64, ARM (including
tranditional and thumb2), ARM64, PPC, PPC64, PPC64LE, MIPS, and MIPS64.

Regards,
Yusuke Suzuki

On Mon, Nov 20, 2017 at 10:48 AM, Yusuke SUZUKI 
wrote:

> Hello WebKittens,
>
> I've just landed the patch[1] introducing CPU(UNKNOWN) and dropping many
> minor CPUs.
>
> CPU(UNKNOWN) is a conservative CPU which handles uknown CPUs. It allows
> minor CPUs
> incuding future CPUs to build WebKit without adding a new CPU types to
> source code.
> And this cleans up source code much by dropping many minor CPUs.
>
> Dropped minor CPUs are ALPHA, HPPA, IA64, SH4, S390X, and S390.
> If you are maintaining one of them and encounter some failures, please
> open a bug for that.
> CPU(UNKNOWN) should keep them working.
>
> Best regards,
> Yusuke Suzuki
>
> [1]: https://trac.webkit.org/r225040
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Heads up: Handling many minor CPUs as CPU(UNKNOWN)

[Yusuke SUZUKI]

Hello WebKittens,

I've just landed the patch[1] introducing CPU(UNKNOWN) and dropping many
minor CPUs.

CPU(UNKNOWN) is a conservative CPU which handles uknown CPUs. It allows
minor CPUs
incuding future CPUs to build WebKit without adding a new CPU types to
source code.
And this cleans up source code much by dropping many minor CPUs.

Dropped minor CPUs are ALPHA, HPPA, IA64, SH4, S390X, and S390.
If you are maintaining one of them and encounter some failures, please open
a bug for that.
CPU(UNKNOWN) should keep them working.

Best regards,
Yusuke Suzuki

[1]: https://trac.webkit.org/r225040
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is git.webkit.org stopping?

[Yusuke SUZUKI]

git.webkit.org seems working now! Thank you for your tough work :D

Regards,
Yusuke Suzuki

On Mon, Sep 18, 2017 at 11:49 PM, Lucas Forschler 
wrote:

> I see that git is at 222138, and svn is at 222143.
> I’ll start investigating, thanks for the heads up!
>
> Lucas
>
>
>
> On Sep 18, 2017, at 6:37 AM, Yusuke SUZUKI  wrote:
>
> Hi WebKittens,
>
> I've found that git.webkit.org is not in sync right now, is it known
> issue?
>
> 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] Is git.webkit.org stopping?

[Yusuke SUZUKI]

Hi WebKittens,

I've found that git.webkit.org is not in sync right now, is it known issue?

Best regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SVN server broken?

[Yusuke SUZUKI]

I saw that WebKit.git stops.

https://git.webkit.org/?p=WebKit.git;a=summary

On Sat, Sep 9, 2017 at 1:29 Alexey Proskuryakov  wrote:

>
> Is anyone still seeing issues? I see a number of patches landed overnight,
> including by commit queue.
>
> One problem I do see is that trac is stale.
>
> - Alexey
>
>
> 8 сент. 2017 г., в 3:19, Carlos Alberto Lopez Perez 
> написал(а):
>
>
> On 08/09/17 11:56, Carlos Alberto Lopez Perez wrote:
>
> On 08/09/17 04:07, Ling Ho wrote:
>
> We have completed server maintenance works. Please email
> ad...@webkit.org if you encounter any problem.
>
>
> It seems there is an issue with the SVN server?
> Is rejecting both commits from commit-queue or manually landed.
>
> $ git svn dcommit
> Committing to http://svn.webkit.org/repository/webkit/trunk ...
> D Tools/wpe/patches/freetype6-2.4.11-truetype-font-height-fix.patch
> M Source/WebCore/ChangeLog
>
> ERROR from SVN:
> Item is out of date: File '/trunk/Source/WebCore/ChangeLog' is out of date
> W: 7e9ab8012eb85cca13a55ea65bc0f194c37a11b7 and refs/remotes/origin/master
> differ, using rebase:
> :04 04 a0c128f45219a4f568ffb7b27336ca501b1fc64f
> 5f584218e40d75a9c39c52b76fd648459857f264 M Source
> :04 04 42e7bcb4148039d4fcc172c267b7db51f0ee98f8
> 7faa3cb8917a0bdbd9d0d34942b8d5422ee72eb9 M Tools
> Current branch master is up to date.
> ERROR: Not all changes have been committed into SVN, however the committed
> ones (if any) seem to be successfully integrated into the working tree.
> Please see the above messages for details.
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> Also SVN trunk is still at r221777, but on the IRC channel #webkit WKR
> has claimed to have landed r221778 and r221779 (and closed bugs 176252
> and 176303), and I can't see this commits anywhere on the SVN.
>
> ___
> 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
>
-- 
Regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Yusuke SUZUKI]

On Wed, Sep 6, 2017 at 3:24 AM, Filip Pizlo  wrote:

>
>
> > On Sep 5, 2017, at 10:51 AM, Olmstead, Don 
> wrote:
> >
> > We have plans to add a JSC-Only windows bot in the very near future.
> Would that have any bearing on the state of JIT in Windows?
>
> Not really.
>
> Because of the poor state of that code, I think we should rip it out.
>
> Also maintaining the 32_64 value representation is no value for us.
>

I think keeping Windows support would be good. I believe Sony folks are
working on Windows improvement, and it would be fine if they can keep
watching JSC on Windows.
And it means that we can keep WebKit fast at major latest architectures
including macOS / Linux / Windows (with 64bit CPUs), which is fine.

My largest concern about dropping JIT for various platforms is that LLInt
performance would be not good compared to JIT-ed environment.
We could remove DFG for 32bit (not sure). But I think PolyIC can be
critical for performance.
JS performance largely depends on this feature.

BTW, I strongly agree that newer feature should focus on 64bit
architecture. (I'm opposed to adding 32bit support to FTL).



>
> -Filip
>
>
> >
> > -Original Message-
> > From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf
> Of Filip Pizlo
> > Sent: Tuesday, September 5, 2017 8:37 AM
> > To: Adrian Perez de Castro 
> > Cc: webkit-dev@lists.webkit.org
> > Subject: Re: [webkit-dev] Bring back ARMv6 support to JSC
> >
> > There isn’t anyone maintaining the 32-not JIT ports to the level of
> quality we have in our 64-not ports. Making 32-bit use the 64-bit cloop
> would be a quality progression for actual users of 32-bit.
> >
> > -Filip
> >
> >>> On Sep 5, 2017, at 8:02 AM, Adrian Perez de Castro 
> wrote:
> >>>
> >>> On Tue, 5 Sep 2017 16:38:09 +0200, Osztrogonác Csaba <
> o...@inf.u-szeged.hu> wrote:
> >>>
> >>> [...]
> >>>
> >>> Maybe it will be hard to say good bye to 32-bit architecutres for
> >>> many people, but please, it's 2017 now, the first ARMv8 SoC is out 4
> >>> years ago, the first AMD64 CPU is out 14 years ago.
> >>
> >> While it's true that amd64/x86_64 has been around long enough to not
> >> have to care (much) about its 32-bit counterpart; the same cannot be
> said about ARM.
> >> It would be great to be able to say that 32-bit ARM is well dead, but
> >> we are not there yet.
> >>
> >> If we take x86_64 as an example, it has been “only” 10 years since the
> >> last new 32-bit CPU was announced and until 3-4 years ago it wasn't
> >> uncommon to see plently of people running 32-bit userlands. If things
> >> unroll in a similar way in the ARM arena, I would expect good 32-bit
> >> ARM support being relevant at least for another 3-4 years before the
> need starts to fade away.
> >>
> >> If something, I think it may make more sense to remove 32-bit x86
> >> support, and have the 32-bit ARM support around for some more time.
> >>
> >> Cheers,
> >>
> >>
> >> --
> >> Adrián 🎩
> >>
> >> ___
> >> 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] [Proposal] Removing OS(SOLARIS) support

[Yusuke SUZUKI]

Removed in r221600.

On Tue, Sep 5, 2017 at 10:03 Yusuke SUZUKI  wrote:

> In addition, I would like to note that our JSVALUE64 is broken in Solaris
> + SPARC 64bit environment
> because its address space includes non-48bit address[1].
> I filed the issue to remove Solaris support from WebKit[2].
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=577056
> [2]: https://bugs.webkit.org/show_bug.cgi?id=176341
>
> On Tue, Sep 5, 2017 at 4:29 AM, Michael Catanzaro 
> wrote:
>
>> On Mon, Sep 4, 2017 at 10:10 AM, Michael Catanzaro 
>> wrote:
>>
>>> I'm pretty sure that no regular contributors to WebKit care about
>>> Solaris support, so I would remove it.
>>>
>>> Michael
>>>
>>
>> Coincidence: apparently Oracle has just fired most of their remaining
>> developers:
>>
>> https://meshedinsights.com/2017/09/03/oracle-finally-killed-sun/
>>
>>
> --
Regards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Proposal] Removing OS(SOLARIS) support

[Yusuke SUZUKI]

In addition, I would like to note that our JSVALUE64 is broken in Solaris +
SPARC 64bit environment
because its address space includes non-48bit address[1].
I filed the issue to remove Solaris support from WebKit[2].

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=577056
[2]: https://bugs.webkit.org/show_bug.cgi?id=176341

On Tue, Sep 5, 2017 at 4:29 AM, Michael Catanzaro 
wrote:

> On Mon, Sep 4, 2017 at 10:10 AM, Michael Catanzaro 
> wrote:
>
>> I'm pretty sure that no regular contributors to WebKit care about Solaris
>> support, so I would remove it.
>>
>> Michael
>>
>
> Coincidence: apparently Oracle has just fired most of their remaining
> developers:
>
> https://meshedinsights.com/2017/09/03/oracle-finally-killed-sun/
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [Proposal] Removing OS(SOLARIS) support

[Yusuke SUZUKI]

Hi WebKittens!

I would like to propose OS(SOLARIS) in WebKit.
I think there are no stake holders supporting Solaris in WebKit.
OS(SOLARIS) a bit complicates our WTF::Thread implementation (StackBounds),
and I don't think it is working right now.
If we can remove OS(SOLARIS), we can also remove COMPILER(SUNCC) too.

What do you think of?

Best reagards,
Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] C++17 is here. Should we use it?

[Yusuke SUZUKI]

I really like C++17, `if with initializer` is super great. Awesome
constexpr lambda and if.
And std::optional and std::variant...

However, IIRC, WebKitGTK+ needs to support some old compilers.
The current GCC support is 5.0.0, which is recently upgraded.
https://bugs.webkit.org/show_bug.cgi?id=174155

Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler
dependencies.

Regards,
Yusuke Suzuki

On Sat, Aug 5, 2017 at 5:39 AM, JF Bastien  wrote:

> Hello WebKilters,
>
> Our Chrome-y friends are considering the use of C++14
> <https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ>.
> I have to say that C++14 in WebKit has been *quite amazing*, and we
> should consider using C++17: it has many wonderful new things
> <https://github.com/tvaneerd/cpp17_in_TTs/blob/master/ALL_IN_ONE.md>,
> some of which we already use through WTF’s re-implementation of library
> features. By now (table as witness
> <http://en.cppreference.com/w/cpp/compiler_support>) most C++17 languages
> features are in clang and GCC, and MSVC isn’t doing too bad either.
> Language things can just come through WTF if we really want them.
>
> So how about it?
>
> JF
>
> ___
> 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] Service workers

[Yusuke SUZUKI]

I've just seen some of initial work about service workers[1,2].
So, have we started experimenting with implementing service workers?

[1]: https://bugs.webkit.org/show_bug.cgi?id=175115
[2]: https://bugs.webkit.org/show_bug.cgi?id=175053

Best regards,
Yusuke Suzuki

On Sat, Jul 15, 2017 at 4:55 AM, Maciej Stachowiak  wrote:

>
>
> > On Jul 13, 2017, at 6:19 PM, Michael Catanzaro 
> wrote:
> >
> > Hi,
> >
> > We've noticed that service worker support has more than once been a
> consideration for embedded device manufacturers when choosing between
> WebKit and Chromium for their products. I see the feature status for
> service workers is currently listed as "under consideration." Are there
> technical concerns with this spec? Is it something that would be desirable
> for WebKit?
>
> Apple engineers from the WebKit team have been heavily involved in
> ServiceWorkers spec discussions over the past few years. Many of our
> concerns with the spec have been addressed, especially for Fetch service
> workers which generally don't run beyond the scope of pages that use them.
> While we have not done any implementation work, the "under consideration"
> in this case is meant literally. We actually are considering it.
>
> More info about who's asking for it and what their use cases are would be
> useful, if you're free to share.
>
> 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] Does someone know how to fix WTF::Function on Windows

[Yusuke SUZUKI]

I'm not 100% confident, but can you try it `&testFunction` instead?

Regards,
Yusuke Suzuki

On Sun, Jul 16, 2017 at 1:13 AM, Darin Adler  wrote:

> Hi folks.
>
> On Windows, WTF::Function doesn’t quite work right. Code that is something
> like this:
>
> void addCallback(WTF::Function&&);
>
> void testFunction()
> {
> // ...
> }
>
> void addTestFunction()
> {
> addCallback(testFunction);
> }
>
> Leads to errors like this:
>
> error C2664: 'void addCallback(WTF::Function &&)': cannot
> convert argument 1 from 'void (__cdecl *)(void)' to 'WTF::Function (void)> &&'
> note: You cannot bind an lvalue to an rvalue reference
>
> The problem might have something to do with cdecl vs. stdcall functions,
> but I am not sure that is the problem. It could be some other problem with
> how WTF::Function is written. Or it might even be a bug in the Visual
> Studio compiler. Since I don’t have a Windows machine myself, I was trying
> to use EWS to figure this out but that was slow. Then I tried using
> http://webcompiler.cloudapp.net but I could not reproduce any error there
> when I pasted in cut down code; it just compiled fine.
>
> Is there someone who knows how to fix this?
>
> Another way to put this is: We want to take off the explicit WTF::Function
> conversions in functions like canUseWithReason in SimpleLineLayout.cpp,
> Page::Page in Page.cpp, and Worker::Worker in Worker.cpp and have it still
> compile and work on Windows. Other platforms seem to compile fine without
> the explicit WTF::Function.
>
> — 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] update GCC version?

[Yusuke SUZUKI]

OK, I've just landed GCC upgrade in r219186!
After upgrading Windows MSVC to 2017, we will get full C++14 environment!

Regards,
Yusuke Suzuki

On Thu, Jul 6, 2017 at 12:10 AM, Michael Catanzaro 
wrote:

> On Wed, Jul 5, 2017 at 6:32 AM, Carlos Alberto Lopez Perez <
> clo...@igalia.com> wrote:
>
>> I think the default build toolchain should be supported also,
>> at least without the requirement of "one year after the release".
>>
>> I propose this change to the policy over yours:
>>
>> - This policy applies to runtime dependencies to ensure smooth updates
>> for users.
>> - It does not apply to the build toolchain.
>> - A compiler other than the default compiler in an otherwise-supported
>> distribution may be required to build.
>>
>> + This policy applies to the runtime dependencies to ensure smooth
>> updates for users.
>> + The requirement of "one year after the release" does not apply to the
>> default toolchain.
>> + On that extra year of support a compiler other than the default one in
>> an otherwise-supported distribution may be required to build.
>>
>>
>> I think is important to not require a too much new version of the default
>> toolchain (GCC).
>>
>
> Fine by me.
>
> 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] update GCC version?

[Yusuke SUZUKI]

I've just opened the bug for upgrading GCC version.

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

Regards,
Yusuke Suzuki

On Tue, Jun 27, 2017 at 2:21 AM, Olmstead, Don 
wrote:

> Same for our WinCairo bots which embed it into a Docker image,
> https://hub.docker.com/r/webkitdev/buildbot/.
>
> The same images should be fine for AppleWin but it's not something I've
> tested.
>
> -Original Message-
> From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf
> Of Alex Christensen
> Sent: Friday, June 23, 2017 1:56 PM
> To: Michael Catanzaro 
> Cc: webkit-...@lists.webkit.org; WebKit-Dev 
> Subject: Re: [webkit-dev] update GCC version?
>
> I’ve been using MSVC 2017 on my WinCairo bot for a while now and it builds
> fine.  It would take a bit to update our internal Windows infrastructure,
> but we should do that soon.
>
>
> ___
> 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