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

2020-07-15 Thread 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

2020-07-11 Thread 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

2020-06-22 Thread 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

2020-06-17 Thread 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

2020-06-17 Thread 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

2020-01-13 Thread 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

2020-01-13 Thread 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

2019-11-01 Thread 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*

2019-10-22 Thread 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

2019-10-17 Thread 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

2019-10-17 Thread 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

2019-10-08 Thread 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

2019-09-16 Thread 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

2019-09-14 Thread 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

2019-09-13 Thread 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

2019-09-13 Thread 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

2019-08-19 Thread 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

2019-08-19 Thread 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?

2019-06-27 Thread 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.webkit.org/pipermail/web

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

2019-06-25 Thread 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

2019-06-10 Thread 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?

2019-05-10 Thread 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

2019-01-02 Thread 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

2018-12-13 Thread 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)?

2018-11-02 Thread 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

2018-09-21 Thread 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.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit_fork_and_compilation.md>"
>&

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

2018-09-21 Thread 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

2018-09-20 Thread 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-iterativ

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

2018-09-19 Thread 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.256+-2.876
&

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

2018-09-19 Thread 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

2018-09-14 Thread 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?

2018-08-28 Thread 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?

2018-08-28 Thread 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?

2018-08-28 Thread 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?

2018-08-28 Thread 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

2018-07-29 Thread 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

2018-07-29 Thread 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

2018-07-14 Thread 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

2018-06-26 Thread 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)

2018-05-23 Thread 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

2018-05-21 Thread Yusuke SUZUKI
Thanks,

On Tue, May 22, 2018 at 1:30 AM Alexey Proskuryakov <a...@webkit.org> 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 <utatane@gmail.com> написал(а):
>
> 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

2018-05-21 Thread 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)

2018-05-19 Thread 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] Question about ARMv7 JIT maintenance by Apple

2018-05-04 Thread Yusuke SUZUKI
On Sat, May 5, 2018 at 11:27 AM Filip Pizlo <fpi...@apple.com> 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 <utatane@gmail.com> 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

2018-05-04 Thread 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

2018-05-02 Thread Yusuke SUZUKI
Thanks, it sounds reasonable :)

On Tue, May 1, 2018 at 1:47 Geoffrey Garen <gga...@apple.com> 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 <utatane@gmail.com>
> 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

2018-04-30 Thread 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] Be careful for using `new builtin[xxx]` / `make_unique<builtin[]>(num)`

2018-02-20 Thread Yusuke SUZUKI
Hi WebKittens,

I recently saw several `make_unique<builtin[]>(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<char[]>(num)` will allocate buffer from system
malloc.

If you use `std::make_unique<XXX[]>(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<char[], XXX>'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

2018-02-05 Thread Yusuke SUZUKI
On Mon, Feb 5, 2018 at 5:24 AM, Alexey Proskuryakov <a...@webkit.org> wrote:

>
> > 4 февр. 2018 г., в 7:09, Yusuke SUZUKI <utatane@gmail.com>
> написал(а):
> >
> > 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

2018-02-04 Thread 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

2018-01-05 Thread 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 <mcatanz...@igalia.com> 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

2017-12-06 Thread Yusuke SUZUKI
Thank you for your replies!

On Wed, Dec 6, 2017 at 8:48 AM, Olmstead, Don <don.olmst...@sony.com> 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 <msab...@apple.com>
> *Cc:* John N. Lehner <jleh...@apple.com>; 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 <msab...@apple.com> 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 <msab...@apple.com> 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 <rn...@webkit.org> 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 <utatane@gmail.com>
> 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

2017-12-05 Thread 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)

2017-11-19 Thread 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 <utatane@gmail.com>
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


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

2017-09-18 Thread 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 <lforsch...@apple.com>
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 <utatane@gmail.com> 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?

2017-09-18 Thread 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?

2017-09-08 Thread 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 <a...@webkit.org> 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 <clo...@igalia.com>
> написал(а):
>
>
> 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

2017-09-07 Thread 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

2017-09-04 Thread Yusuke SUZUKI
Removed in r221600.

On Tue, Sep 5, 2017 at 10:03 Yusuke SUZUKI <utatane@gmail.com> 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 <mcatanz...@igalia.com>
> wrote:
>
>> On Mon, Sep 4, 2017 at 10:10 AM, Michael Catanzaro <mcatanz...@igalia.com>
>> 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

2017-09-04 Thread 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

2017-09-04 Thread 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?

2017-08-04 Thread 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 <jfbast...@apple.com> 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_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

2017-08-03 Thread 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 <m...@apple.com> wrote:

>
>
> > On Jul 13, 2017, at 6:19 PM, Michael Catanzaro <mcatanz...@igalia.com>
> 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

2017-07-15 Thread Yusuke SUZUKI
I'm not 100% confident, but can you try it `` instead?

Regards,
Yusuke Suzuki

On Sun, Jul 16, 2017 at 1:13 AM, Darin Adler <da...@apple.com> wrote:

> Hi folks.
>
> On Windows, WTF::Function doesn’t quite work right. Code that is something
> like this:
>
> void addCallback(WTF::Function<void()>&&);
>
> 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?

2017-07-05 Thread 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 <mcatanz...@igalia.com>
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?

2017-07-05 Thread 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 <don.olmst...@sony.com>
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 <mcatanz...@igalia.com>
> Cc: webkit-...@lists.webkit.org; WebKit-Dev <webkit-dev@lists.webkit.org>
> 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


Re: [webkit-dev] update GCC version?

2017-06-23 Thread Yusuke SUZUKI
It's middle of 2017! And Debian stable is released.

We discussed a bit about updating GCC and MSVC in [1].
Based on the comment from JF[1], I think start of July would be very nice
timing to update our GCC version.

If we can update our compiler baselines including MSVC, it would be very
nice to us because it means full C++14 support at least.

[1]: https://bugs.webkit.org/show_bug.cgi?id=173582
[2]: https://bugs.webkit.org/show_bug.cgi?id=173582#c10

Regards,
Yusuke Suzuki

On Tue, Jan 10, 2017 at 4:44 AM, Alberto Garcia <be...@igalia.com> wrote:

> On Mon, Jan 09, 2017 at 04:39:44PM +0100, Carlos Alberto Lopez Perez wrote:
>
> > I strongly oppose to do (a). Also, it is false that Debian doesn't
> > take our updates. They take our updates in the backports repository
> > for stable.
>
> The main reason why that happens is that the WebKitGTK+ stable updates
> not only include security fixes but also several other changes, which
> is not how things usually work in Debian:
>
> https://www.debian.org/security/faq#oldversion
>
> Since WebKitGTK+ is conservative regarding API/ABI changes I don't
> think there's much of a risk there, but there's definitely a risk
> of introducing regressions, and unlike Mozilla or Chromium updating
> WebKitGTK+ can affect or potentially break any of the many packages
> that depend on it.
>
> That's why I started uploading it to the backports repository, and my
> plan is to keep the backports always up to date.
>
> Berto
> ___
> 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 nightly stops

2017-06-19 Thread Yusuke SUZUKI
Thanks! It works fine to me :D

Regards,
Yusuke Suzuki

On Tue, Jun 20, 2017 at 9:05 AM, Ling Ho <lin...@apple.com> wrote:

> Hello Yusuke,
>
> Thanks for reporting the problem! I believe the issue is now fixed.
>
> ...
> ling
>
>
> On 6/16/17 12:23 PM, Yusuke SUZUKI wrote:
>
> Hi WebKittens!
>
> I've found that WebKit nightly build stops after June 13.
> Is there any issues?
>
> And thank you for maintainers of the buildbots!
> WebKit nigthly is very helpful to me :)
>
> Best regards,
> Yusuke Suzuki
>
>
> ___
> webkit-dev mailing 
> listwebkit-dev@lists.webkit.orghttps://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] Why does our std::optional lack the has_value() function?

2017-06-19 Thread Yusuke SUZUKI
Feel free to review it :)
https://bugs.webkit.org/show_bug.cgi?id=173582

Regards,
Yusuke Suzuki

On Tue, Jun 20, 2017 at 1:48 PM, JF Bastien <jfbast...@apple.com> wrote:

> Ours was imported from: https://github.com/akrzemi1/Optional
> at: 727c729dd1d9f06f225868280e50154594d7e59d
>
> And it was subsequently added in: https://github.com/
> akrzemi1/Optional/commit/8993daae3e9ed90be98ffb2517315f43fe9f09e4#diff-
> b7e55535b5ac355f0d683d30b3c87f86
>
>
>
> On Jun 19, 2017, at 21:45, Darin Adler <da...@apple.com> wrote:
>
> I noticed we don’t have has_value() in our version of std::optional. Does
> anyone know why?
>
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Why does our std::optional lack the has_value() function?

2017-06-19 Thread Yusuke SUZUKI
I think it is just missing in the original code.

Seeing the original repository, we can find that these things are added.
We can rebaseline our copy by applying these changes.

https://github.com/akrzemi1/Optional/commits/master

Regards,
Yusuke Suzuki

On Tue, Jun 20, 2017 at 1:45 PM, Darin Adler <da...@apple.com> wrote:

> I noticed we don’t have has_value() in our version of std::optional. Does
> anyone know why?
>
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebKit nightly stops

2017-06-16 Thread Yusuke SUZUKI
Hi WebKittens!

I've found that WebKit nightly build stops after June 13.
Is there any issues?

And thank you for maintainers of the buildbots!
WebKit nigthly is very helpful to me :)

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


Re: [webkit-dev] Jiewen Tan is now a WebKit reviewer

2017-05-31 Thread Yusuke SUZUKI
Congrats!

Regards,
Yusuke Suzuki

On Thu, Jun 1, 2017 at 6:18 AM, Mark Lam <mark@apple.com> wrote:

> Hi everyone,
>
> I would like to announce that Jiewen Tan (jiewen on #webkit) is now a
> WebKit reviewer.  Jiewen usually works on the WebCrypto API.
>
> Please join me in congratulating Jiewen, and send him some patches to
> review.
>
> Jiewen, congratulations.
>
> Mark
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Konstantin Tokarev is now a WebKit reviewer

2017-05-22 Thread Yusuke SUZUKI
Congrats!

On Tue, May 23, 2017 at 2:25 Mark Lam <mark@apple.com> wrote:

> Hi everyone,
>
> I would like to announce that Konstantin Tokarev (annulen on #webkit) is
> now a WebKit reviewer.  Konstantin has extensive knowledge of WebKit, and
> has resurrected the QtWebKit port, helped WebKit compete against Chromium
> in the Qt project, and ensured that the dozens of applications that depend
> on QtWebKit will soon be able to receive updated versions of WebKit.
>
> Please join me in congratulating Konstantin, and send him some patches to
> review.
>
> Konstantin, congratulations.
>
> Mark
> ___
> 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] Reminder: be careful when printing sized integer types

2017-05-11 Thread Yusuke SUZUKI
Or, alternative way is casting the value to `unsigned long long` and always
using %llu for uint64_t.

uint64_t value = ...;
printf("%llu", (unsigned long long)value);

Regards,
Yusuke Suzuki

On Wed, May 10, 2017 at 4:07 AM, Michael Catanzaro <mcatanz...@igalia.com>
wrote:

> Hi,
>
> This is just a reminder to avoid a case that occasionally causes warnings
> for GTK+. On Mac, uint64_t is (I assume) a typedef for unsigned long long.
> But on Linux 86_64 it's a typedef for unsigned long. This means they have
> to be printed differently. Using "%llu" to print a uint64_t (presumably)
> works on Mac, but it causes compiler warnings on Linux. The right way is
> unfortunately to use "%" PRIu64, which expands to "%llu" on Mac and "%lu"
> on Linux. There are variants on these macros for many different integer
> types: http://en.cppreference.com/w/cpp/types/integer
>
> It's verbose, but helps us avoid warnings. And since it's declared in
> stdint.h/cstdint, if you're using uint64_t then it's already available.
>
> Thanks,
>
> 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] nightly.webkit.org server transition this evening

2017-04-16 Thread Yusuke SUZUKI
Hi,

Seems like nightly build stoped at March 29. Is that an known issue?

Regards,
Yusuke Suzuki

On Wed, Mar 22, 2017 at 4:31 AM, Lucas Forschler <lforsch...@apple.com>
wrote:

> This should now be fixed. Please let me know if you notice any problems
> with the nightly.
> Lucas
>
> On Mar 21, 2017, at 8:08 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>
> Hi Lucas,
>
> On Wed, Mar 22, 2017 at 12:06 AM, Lucas Forschler <lforsch...@apple.com>
> wrote:
>
>> Hi Yusuke,
>>
>> I am aware of the issue. The nightlies are uploading, but are not being
>> registered in the database. I hope to have a fix this week.
>>
>
> OK, thank you so much for your help!
>
>
>> Lucas
>>
>> On Mar 21, 2017, at 1:09 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>>
>> Hi,
>>
>> it seems that WebKit nightly build stops. Is it related to this change?
>>
>> Regards,
>> Yusuke Suzuki
>>
>> On Tue, Mar 14, 2017 at 6:33 AM, Lucas Forschler <lforsch...@apple.com>
>> wrote:
>>
>>> Hello folks,
>>>
>>> We are going to start transitioning nightly.webkit.org to new hardware
>>> today. We expect the DNS change to happen in the next 2 hours. At that
>>> point, nightly.webkit.org should resolve to 54.190.50.179. Please let
>>> us know if you run into any issues reaching or navigating the site,
>>> downloading archives (new or old), or with the update mechanism of the
>>> WebKit nightly.
>>>
>>> Thanks,
>>> Lucas
>>>
>>>
>>> ___
>>> 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] nightly.webkit.org server transition this evening

2017-03-21 Thread Yusuke SUZUKI
Hi Lucas,

On Wed, Mar 22, 2017 at 12:06 AM, Lucas Forschler <lforsch...@apple.com>
wrote:

> Hi Yusuke,
>
> I am aware of the issue. The nightlies are uploading, but are not being
> registered in the database. I hope to have a fix this week.
>

OK, thank you so much for your help!


> Lucas
>
> On Mar 21, 2017, at 1:09 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>
> Hi,
>
> it seems that WebKit nightly build stops. Is it related to this change?
>
> Regards,
> Yusuke Suzuki
>
> On Tue, Mar 14, 2017 at 6:33 AM, Lucas Forschler <lforsch...@apple.com>
> wrote:
>
>> Hello folks,
>>
>> We are going to start transitioning nightly.webkit.org to new hardware
>> today. We expect the DNS change to happen in the next 2 hours. At that
>> point, nightly.webkit.org should resolve to 54.190.50.179. Please let us
>> know if you run into any issues reaching or navigating the site,
>> downloading archives (new or old), or with the update mechanism of the
>> WebKit nightly.
>>
>> Thanks,
>> Lucas
>>
>>
>> ___
>> 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] nightly.webkit.org server transition this evening

2017-03-21 Thread Yusuke SUZUKI
Hi,

it seems that WebKit nightly build stops. Is it related to this change?

Regards,
Yusuke Suzuki

On Tue, Mar 14, 2017 at 6:33 AM, Lucas Forschler <lforsch...@apple.com>
wrote:

> Hello folks,
>
> We are going to start transitioning nightly.webkit.org to new hardware
> today. We expect the DNS change to happen in the next 2 hours. At that
> point, nightly.webkit.org should resolve to 54.190.50.179. Please let us
> know if you run into any issues reaching or navigating the site,
> downloading archives (new or old), or with the update mechanism of the
> WebKit nightly.
>
> Thanks,
> Lucas
>
>
> ___
> 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] Port For Android

2017-03-18 Thread Yusuke SUZUKI
FYI, recently, android port is released by Naver WebKit team
https://lists.webkit.org/pipermail/webkit-dev/2017-March/028836.html

Regards,
Yusuke Suzuki

On Thu, Mar 16, 2017 at 5:38 PM, Sergio Villar Senin <svil...@igalia.com>
wrote:

> O Mar, 07-03-2017 ás 20:07 -0500, Patrick Wright escribiu:
> >
> > However, in the source code of android. There is an implementation of
> > Webkit show here: https://developer.android.com/reference/android/web
> > kit/package-summary.html . it is just very slow and restrictive.
>
> That's the Android WebView which is based on Blink (Chromium). The
> architecture is completely different to desktop Chromium though due to
> platform limitations in Android.
>
> BR
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Introduce WebKit Android port

2017-03-12 Thread Yusuke SUZUKI
Interesting.
Can JSCOnly port accepts the Android porting things into JSC?
I think this should be small enough.

On Sun, Mar 12, 2017 at 9:21 장대웅 <daewoong.j...@navercorp.com> wrote:

> Hello,
>
>
>
> I'd like to let you know: WebKit Android port is available. Please check
> repository on GitHub:
>
> https://github.com/daewoong-jang/webkit-android
>
>
>
> It is based on our web engine project and is totally different from the
> old Android port which had been packaged with AOSP.
>
> The most important difference is that this new Android port adopts modern
> WebKit2 architecture. And it designed to be cross-platform itself so it can
> be built and run on other platforms(only for Windows, for now).
>
>
> You can see more details on GitHub. It is still far from complete, but I'd
> like to let you know that it has begun. I hope this project will help the
> WebKit community to thrive. If you have any questions, send me on email:
> daewoong.j...@navercorp.com(Weekdays) daewoon...@aol.com(Weekends and
> holidays).
>
> Regards,
>
> Daewoong.
>
>
>
> NAVER WebKit Team
>
>
> ___
> 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] Devin Rousso is now a WebKit reviewer

2017-03-09 Thread Yusuke SUZUKI
Congrats! :D

Regards,
Yusuke Suzuki

On Fri, Mar 10, 2017 at 5:49 AM, Mark Lam <mark@apple.com> wrote:

> Hi everyone,
>
> I would like to announce that Devin Rousso (dcrousso on #webkit) is now a
> WebKit reviewer.  Devin has been contributing to Web Inspector for nearly
> two years.  Please join me in congratulating Devin, and send him some
> patches to review.
>
> Devin, congratulations.
>
> Mark
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit GPU rendering possibility

2017-01-26 Thread Yusuke SUZUKI
I and Kevin worked on removing boost dependencies in fastuidraw.
And now, we completely remove its dependencies.

Regards,
Yusuke Suzuki

On Wed, Nov 23, 2016 at 5:33 AM, Rogovin, Kevin <kevin.rogo...@intel.com>
wrote:

> Hi,
>
>  There is quite likely ways around using boost. It's main use is to
> provide mutex, threading and atomic, which is quite easy to do another way.
> The harder to replace of boost is in how FastUIDraw handles loading front
> via FreeType I want to change in a big way and killing the boost dependency
> is one of those goals.
>
> -Kevin
>
> --
> *From:* Olmstead, Don [don.olmst...@sony.com]
> *Sent:* Tuesday, November 22, 2016 9:04 PM
> *To:* Rogovin, Kevin; webkit-dev@lists.webkit.org
> *Subject:* RE: WebKit GPU rendering possibility
>
> We actually mentioned fastuidraw while we were at the contributors meeting
> as a potential replacement for our Cairo rendering for PlayStation. When we
> got to a point with our port where we can start evaluating we’d be
> interested in taking a look. The only problem I had with the setup was a
> reliance on boost, but maybe there are ways around it.
>
>
>
> *From:* webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-bounces@
> lists.webkit.org] *On Behalf Of *Rogovin, Kevin
> *Sent:* Wednesday, November 2, 2016 9:36 AM
> *To:* webkit-dev@lists.webkit.org
> *Subject:* [webkit-dev] WebKit GPU rendering possibility
>
>
>
> Hi,
>
>
>
> I was directed here by some colleagues as this is the place to post the
> following to get started on the following proposal.
>
>
>
> I have been working on an experimental 2D renderer that requires a GPU,
> the project is open sourced on github at https://github.com/01org/
> fastuidraw. I gave a talk at the X Developers Conference this year which
> can be seen from https://www.x.org/wiki/Events/
> XDC2016/Program/rogovin_fast_ui_draw/ .
>
>
>
> I made a benchmark which makes heavy use of rotations and clipping and
> ported to SKIA, Qt’s QPainter and Cairo. The benchmark and its ports are in
> the git repo linked above under the branch with_ports_of_painter-cells.
> It's performance advantage of FastUIDraw against the other renderers was
> quite severe (against Cairo and Qt's QPainter over 9 times and against SKIA
> about 5 times faster).
>
>
>
> I would like to explore the option of using FastUIDraw to implement a
> WebCore::GraphicsContext backend for the purpose of making drawing faster
> and more efficient on Intel devices that are equipped with a GPU. I also
> think that some minor modifications to WebKit’s use of GraphicsContext will
> also give some benefits. I have worked on WebKit a few years ago and
> knew/know my way around the rendering code very well (atleast at that time).
>
>
>
> Looking forward to collaboration,
>
> -Kevin Rogovin
>
>
>
> ___
> 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] Thread naming policy in WebKit

2017-01-09 Thread Yusuke SUZUKI
Thank you for your suggestions!
Based on our discussion, I've uploaded the patch[1] :)

[1]: https://bugs.webkit.org/show_bug.cgi?id=166678

Regards,
Yusuke Suzuki

On Fri, Jan 6, 2017 at 2:50 PM, Yusuke SUZUKI <utatane@gmail.com> wrote:

> On Fri, Jan 6, 2017 at 2:43 PM, Maciej Stachowiak <m...@apple.com> wrote:
>
>>
>> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>>
>> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak <m...@apple.com> wrote:
>>
>>>
>>> On Jan 5, 2017, at 9:37 AM, Brady Eidson <beid...@apple.com> wrote:
>>>
>>>
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane@gmail.com>
>>> wrote:
>>>
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com> wrote:
>>>
>>>> I understand the appeal of “org.webkit” and structured names but
>>>> personally I would prefer to read names that look like titles and are made
>>>> up of words with spaces, like these:
>>>>
>>>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>>>> “WebKit: JavaScript DFG Compiler” rather than
>>>> “org.webkit.jsc.DFGCompiler”.
>>>>
>>>> Not sure how well that would generalize to all the different names.
>>>>
>>>> I like the idea of having a smart way of automatically making a shorter
>>>> name for the platforms that have shorter length limits.
>>>>
>>>
>>> One interesting idea I've come up with is that,
>>>
>>> 1. specifying "org.webkit.ImageDecoder"
>>> 2. In Linux, we just use "ImageDecoder" part.
>>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>>>
>>>
>>> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
>>> part is ever going to be used?
>>> Is that because Windows could use “org.webkit.”?
>>>
>>>
>>> What about if you just specify "Image Decoder" and we automatically
>>> convert that to either "ImageDecoder" or "WebKit: Image Decoder" based on
>>> platform thread name limits? Is there any case where we want a prefix other
>>> than "WebKit: "?
>>>
>>
>> Yeah. For the prefix case, automatically adding "WebKit: " is fine. The
>> current ToT has the name like "com.apple.IPC.ReceiveQueue".
>> Previously I thought that we may need to convert it to "Apple WebKit:" or
>> something like that.
>> But now, I think simply using "WebKit: IPC Receive Queue" is fine.
>>
>> But I think automatically changing "ImageDecoder" to "Image Decoder" does
>> not work well with long names.
>> There is a name like "AsynchrnousDisassembler". It is >= 15 characters.
>> "AsynchronousDisas" is not good for Linux.
>> On the other hand, using "AsyncDisasm" => "WebKit: AsyncDisasm" is not
>> good for macOS.
>> For macOS, we can choose more readable name like "WebKIt: Asynchronous
>> Disassembler".
>>
>> So, I think Geoffrey's suggestion works well: using long / short name
>> pairs. Like,
>>
>> ThreadName { "Asynchronous Disassembler", "AsyncDisasm" } // { const
>> char*, const char* }
>>
>> // OR,
>> CREATE_THREAD_NAME("Asynchronous Disassembler", "AsyncDisasm") macro =>
>> generating ThreadName("WebKit: Asynchronous Disassembler") on macOS,
>> ThreadName("AsyncDisasm") on Linux
>>
>>
>> If there's a good set of "short name" and "long name" length limits, it
>> would be cool if we could check the length at compile time, which seems
>> more feasible with the macro.
>>
>>
> Yeah! That's what I would like to do. The typical ThreadName
> implementation would become the following.
>
> class ThreadName {
> public:
> template
> explicit ThreadName(const char ()[N])
> : m_name(name)
> {
> #if OS(LINUX)
> static_assert(N <= 16, "");
> #else if OS(WINDOWS)
> static_assert(N <= 32, "");
> #endif
> }
>
> operator const char*()
> {
> return m_name;
> }
>
> private:
> const char* m_name;
> };
>
>
>
>> Regards,
>> Maciej
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-01-05 Thread Yusuke SUZUKI
On Fri, Jan 6, 2017 at 2:43 PM, Maciej Stachowiak <m...@apple.com> wrote:

>
> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>
> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak <m...@apple.com> wrote:
>
>>
>> On Jan 5, 2017, at 9:37 AM, Brady Eidson <beid...@apple.com> wrote:
>>
>>
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>>
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com> wrote:
>>
>>> I understand the appeal of “org.webkit” and structured names but
>>> personally I would prefer to read names that look like titles and are made
>>> up of words with spaces, like these:
>>>
>>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>>> “WebKit: JavaScript DFG Compiler” rather than
>>> “org.webkit.jsc.DFGCompiler”.
>>>
>>> Not sure how well that would generalize to all the different names.
>>>
>>> I like the idea of having a smart way of automatically making a shorter
>>> name for the platforms that have shorter length limits.
>>>
>>
>> One interesting idea I've come up with is that,
>>
>> 1. specifying "org.webkit.ImageDecoder"
>> 2. In Linux, we just use "ImageDecoder" part.
>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>>
>>
>> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
>> part is ever going to be used?
>> Is that because Windows could use “org.webkit.”?
>>
>>
>> What about if you just specify "Image Decoder" and we automatically
>> convert that to either "ImageDecoder" or "WebKit: Image Decoder" based on
>> platform thread name limits? Is there any case where we want a prefix other
>> than "WebKit: "?
>>
>
> Yeah. For the prefix case, automatically adding "WebKit: " is fine. The
> current ToT has the name like "com.apple.IPC.ReceiveQueue".
> Previously I thought that we may need to convert it to "Apple WebKit:" or
> something like that.
> But now, I think simply using "WebKit: IPC Receive Queue" is fine.
>
> But I think automatically changing "ImageDecoder" to "Image Decoder" does
> not work well with long names.
> There is a name like "AsynchrnousDisassembler". It is >= 15 characters.
> "AsynchronousDisas" is not good for Linux.
> On the other hand, using "AsyncDisasm" => "WebKit: AsyncDisasm" is not
> good for macOS.
> For macOS, we can choose more readable name like "WebKIt: Asynchronous
> Disassembler".
>
> So, I think Geoffrey's suggestion works well: using long / short name
> pairs. Like,
>
> ThreadName { "Asynchronous Disassembler", "AsyncDisasm" } // { const
> char*, const char* }
>
> // OR,
> CREATE_THREAD_NAME("Asynchronous Disassembler", "AsyncDisasm") macro =>
> generating ThreadName("WebKit: Asynchronous Disassembler") on macOS,
> ThreadName("AsyncDisasm") on Linux
>
>
> If there's a good set of "short name" and "long name" length limits, it
> would be cool if we could check the length at compile time, which seems
> more feasible with the macro.
>
>
Yeah! That's what I would like to do. The typical ThreadName implementation
would become the following.

class ThreadName {
public:
template
explicit ThreadName(const char ()[N])
: m_name(name)
{
#if OS(LINUX)
static_assert(N <= 16, "");
#else if OS(WINDOWS)
static_assert(N <= 32, "");
#endif
}

operator const char*()
{
return m_name;
}

private:
const char* m_name;
};



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


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

2017-01-05 Thread Yusuke SUZUKI
On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak <m...@apple.com> wrote:

>
> On Jan 5, 2017, at 9:37 AM, Brady Eidson <beid...@apple.com> wrote:
>
>
> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>
> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com> wrote:
>
>> I understand the appeal of “org.webkit” and structured names but
>> personally I would prefer to read names that look like titles and are made
>> up of words with spaces, like these:
>>
>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>> “WebKit: JavaScript DFG Compiler” rather than
>> “org.webkit.jsc.DFGCompiler”.
>>
>> Not sure how well that would generalize to all the different names.
>>
>> I like the idea of having a smart way of automatically making a shorter
>> name for the platforms that have shorter length limits.
>>
>
> One interesting idea I've come up with is that,
>
> 1. specifying "org.webkit.ImageDecoder"
> 2. In Linux, we just use "ImageDecoder" part.
> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>
>
> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
> part is ever going to be used?
> Is that because Windows could use “org.webkit.”?
>
>
> What about if you just specify "Image Decoder" and we automatically
> convert that to either "ImageDecoder" or "WebKit: Image Decoder" based on
> platform thread name limits? Is there any case where we want a prefix other
> than "WebKit: "?
>

Yeah. For the prefix case, automatically adding "WebKit: " is fine. The
current ToT has the name like "com.apple.IPC.ReceiveQueue".
Previously I thought that we may need to convert it to "Apple WebKit:" or
something like that.
But now, I think simply using "WebKit: IPC Receive Queue" is fine.

But I think automatically changing "ImageDecoder" to "Image Decoder" does
not work well with long names.
There is a name like "AsynchrnousDisassembler". It is >= 15 characters.
"AsynchronousDisas" is not good for Linux.
On the other hand, using "AsyncDisasm" => "WebKit: AsyncDisasm" is not good
for macOS.
For macOS, we can choose more readable name like "WebKIt: Asynchronous
Disassembler".

So, I think Geoffrey's suggestion works well: using long / short name
pairs. Like,

ThreadName { "Asynchronous Disassembler", "AsyncDisasm" } // { const char*,
const char* }

// OR,
CREATE_THREAD_NAME("Asynchronous Disassembler", "AsyncDisasm") macro =>
generating ThreadName("WebKit: Asynchronous Disassembler") on macOS,
ThreadName("AsyncDisasm") on Linux


>  - Maciej
>
>
> Again, back to Darin’s point, I don’t see any particular value in ever
> seeing “org.webkit.”
>
> Additionally, the way this proposal treats “ImageDecoder” as multiple
> words, presumably separated on case-change, is problematic.
>
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”,
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called,
> would expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
>
> —
>
> Taking your proposal and running with it, I think we could do this:
>
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…"
>
> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit:
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
>
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous
> Disassembler"
>
> Addendum: If we see value in having somethings flagged as “JSC” instead of
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific
> feature could be “WebKit. IndexedDB Server”
>
> Thanks,
> ~Brady
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-01-05 Thread Yusuke SUZUKI
Regards,
Yusuke Suzuki

On Fri, Jan 6, 2017 at 5:34 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:

> On Fri, Jan 6, 2017 at 2:37 AM, Brady Eidson <beid...@apple.com> wrote:
>
>>
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>>
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com> wrote:
>>
>>> I understand the appeal of “org.webkit” and structured names but
>>> personally I would prefer to read names that look like titles and are made
>>> up of words with spaces, like these:
>>>
>>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>>> “WebKit: JavaScript DFG Compiler” rather than
>>> “org.webkit.jsc.DFGCompiler”.
>>>
>>> Not sure how well that would generalize to all the different names.
>>>
>>> I like the idea of having a smart way of automatically making a shorter
>>> name for the platforms that have shorter length limits.
>>>
>>
>> One interesting idea I've come up with is that,
>>
>> 1. specifying "org.webkit.ImageDecoder"
>> 2. In Linux, we just use "ImageDecoder" part.
>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>>
>>
>> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
>> part is ever going to be used?
>> Is that because Windows could use “org.webkit.”?
>>
>>
> Yup, we can drop this part. Originally, I was considering about 
> "com.apple.IPC.ReceiveQueue"
> in WebKit2 thread => "Apple WebKit: xxx".
> But I think just using "WebKit: " is OK.
>
>
>> Again, back to Darin’s point, I don’t see any particular value in ever
>> seeing “org.webkit.”
>>
>> Additionally, the way this proposal treats “ImageDecoder” as multiple
>> words, presumably separated on case-change, is problematic.
>>
>> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”,
>> different from today.
>> e.g. “IndexedDBServer”, which is probably what this should be called,
>> would expand to “Indexed D B Server"
>> e.g. “GCController” would expand to “G C Controller”
>>
>
> If we recognize the [UpperCharacter]*[LowerCharacter]* as word, we can
> split it as "GC Controller".
>

Oops, I mean using ([UpperCharacter][LowerCharacter]) to split the word.


> But anyway, it causes a problem when we encounter a name like
> "XMLDBController".
>
>
>>
>> —
>>
>> Taking your proposal and running with it, I think we could do this:
>>
>> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>>
>> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
>> 2a - It could get truncated with ellipses: “AsynchronousDi…"
>>
>
> I think we should not truncate the name for Linux.
> My automatic shortening is based on the fact that "org.webkit.MODULE.NAME"'s
> NAME part is always <= 15 characters. So we do not truncate.
>
> But if we have names like "Asynchronous Indexed Database Server" and
> "Asynchronous Indexed Database Client", the both become "AsynchronousIndex"
> in Linux.
> It is not helpful.
>
> However always using 15 characters names effectively limits the ability of
> macOS's thread names.
>
> So now, I like Geoff's idea, having 2 names, long name and short name.
> For example, we have "Asynchronous Disassembler" and "AsyncDisasm".
> Then, in macOS, use "WebKit: Asynchronous Disassembler".
> In Windows, use "WebKit: AsyncDisasm".
> In Linux, use "AsyncDisasm".
>
>
>> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit:
>> Asynchronous Disassemb”
>> 3a - It could get truncated with ellipses: “WebKit: Asynchronous
>> Disassem…”
>>
>> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous
>> Disassembler"
>>
>> Addendum: If we see value in having somethings flagged as “JSC” instead
>> of “WebKit”, we just augment the input to include that.
>> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific
>> feature could be “WebKit. IndexedDB Server”
>>
>
> Yeah, we can add JSC prefix in long name part if we want.
>
>
>>
>> Thanks,
>> ~Brady
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2017-01-05 Thread Yusuke SUZUKI
On Fri, Jan 6, 2017 at 2:37 AM, Brady Eidson <beid...@apple.com> wrote:

>
> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>
> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <da...@apple.com> wrote:
>
>> I understand the appeal of “org.webkit” and structured names but
>> personally I would prefer to read names that look like titles and are made
>> up of words with spaces, like these:
>>
>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>> “WebKit: JavaScript DFG Compiler” rather than
>> “org.webkit.jsc.DFGCompiler”.
>>
>> Not sure how well that would generalize to all the different names.
>>
>> I like the idea of having a smart way of automatically making a shorter
>> name for the platforms that have shorter length limits.
>>
>
> One interesting idea I've come up with is that,
>
> 1. specifying "org.webkit.ImageDecoder"
> 2. In Linux, we just use "ImageDecoder" part.
> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>
>
> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
> part is ever going to be used?
> Is that because Windows could use “org.webkit.”?
>
>
Yup, we can drop this part. Originally, I was considering about
"com.apple.IPC.ReceiveQueue"
in WebKit2 thread => "Apple WebKit: xxx".
But I think just using "WebKit: " is OK.


> Again, back to Darin’s point, I don’t see any particular value in ever
> seeing “org.webkit.”
>
> Additionally, the way this proposal treats “ImageDecoder” as multiple
> words, presumably separated on case-change, is problematic.
>
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”,
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called,
> would expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
>

If we recognize the [UpperCharacter]*[LowerCharacter]* as word, we can
split it as "GC Controller".
But anyway, it causes a problem when we encounter a name like
"XMLDBController".


>
> —
>
> Taking your proposal and running with it, I think we could do this:
>
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…"
>

I think we should not truncate the name for Linux.
My automatic shortening is based on the fact that "org.webkit.MODULE.NAME"'s
NAME part is always <= 15 characters. So we do not truncate.

But if we have names like "Asynchronous Indexed Database Server" and
"Asynchronous Indexed Database Client", the both become "AsynchronousIndex"
in Linux.
It is not helpful.

However always using 15 characters names effectively limits the ability of
macOS's thread names.

So now, I like Geoff's idea, having 2 names, long name and short name.
For example, we have "Asynchronous Disassembler" and "AsyncDisasm".
Then, in macOS, use "WebKit: Asynchronous Disassembler".
In Windows, use "WebKit: AsyncDisasm".
In Linux, use "AsyncDisasm".


> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit:
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
>
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous
> Disassembler"
>
> Addendum: If we see value in having somethings flagged as “JSC” instead of
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific
> feature could be “WebKit. IndexedDB Server”
>

Yeah, we can add JSC prefix in long name part if we want.


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


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

2017-01-05 Thread Yusuke SUZUKI
On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  wrote:

> I understand the appeal of “org.webkit” and structured names but
> personally I would prefer to read names that look like titles and are made
> up of words with spaces, like these:
>
> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
> “WebKit: JavaScript DFG Compiler” rather than “org.webkit.jsc.DFGCompiler”.
>
> Not sure how well that would generalize to all the different names.
>
> I like the idea of having a smart way of automatically making a shorter
> name for the platforms that have shorter length limits.
>

One interesting idea I've come up with is that,

1. specifying "org.webkit.ImageDecoder"
2. In Linux, we just use "ImageDecoder" part.
3. In macOS port, we automatically convert it to "WebKit: Image Decoder"


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


[webkit-dev] Thread naming policy in WebKit

2017-01-04 Thread Yusuke SUZUKI
Hi WebKittens!

Recently, I started naming threads in Linux. And I also started naming
threads created by WTF::AutomaticThread.
Previously, all the thread is not named in Linux. It makes difficult to
find problematic threads when using GDB in Linux.
For example, if you run the JSC shell, all the threads are named as "jsc"
(this is the name of the process).

The problem raised here is that we have no consistent policy for thread
names.
I picked several names in WebKit.

In WebCore,
IDB server is "IndexedDatabase Server"
AsyncAudioDecoder is "Audio Decoder"
GCController is "WebCore: GCController"
Icon Database is "WebCore: IconDatabase"
Audio's ReverbConvolver is "convolution background thread"
The thread name used by WorkQueue in WebCore is,
Crypto Queue is "com.apple.WebKit.CryptoQueue"
Image decoder is "org.webkit.ImageDecoder"
Blob utility is "org.webkit.BlobUtility"
Data URL decoder is "org.webkit.DataURLDecoder"
In JSC
Before this patch, all the AutomaticThreads (including JIT worklist /
DFG worklist) is "WTF::AutomaticThread"
Super Sampler thread is "JSC Super Sampler"
Asychronous Disasm is "Asynchronous Disassembler"
Sampling profiler is "jsc.sampling-profiler.thread"
WASM compiler thread is "jsc.wasm-b3-compilation.thread"
In WebKit2
Network Cache is "IOChannel::readSync"
IPC workqueue is "com.apple.IPC.ReceiveQueue"

To choose the appropriate naming policy, there are two requirements.
This is discussed in https://bugs.webkit.org/show_bug.cgi?id=166678 and
https://bugs.webkit.org/show_bug.cgi?id=166684

1. We should have super descriptive name including the iformation "This
thread is related to WebKit".
If we use WebKit as the framework, WebKit will launch several threads along
with the user application's threads.
So if the thread name does not include the above information, it is quite
confusing: Is this crash related to WebKit OR user's applications?
This should be met at least in macOS port. In the Linux port, this
requirement is a bit difficult to be met due to the second requirement.

2. The thread name should be <= 15 characters in Linux. <= 31 characters in
Windows.
This is super unfortunate. But we need this requirement. But in macOS, I
think we do not have any limitation like that (correct?)
I cannot find "PTHREAD_MAX_NAMELEN_NP" definition in macOS.

To meet the above requirements as much as possible, I suggest the name, "
org.webkit.MODULE.NAME(15characters)".
This policy is derived from the WorkQueue's naming policy, like
"org.webkit.ImageDecoder".
For example, we will name DFG compiler worklist thread as
"org.webkit.jsc.DFGCompiler" or "org.webkit.JavaScriptCore.DFGCompiler".

In Linux / Windows, we have the system to normalize the above name to
"NAME(15characters)".
For example, when you specify "org.webkit.jsc.DFGCompiler", it will be
shown as "DFGCompiler" in Linux.
This naming policy meets (1) in macOS. And (2) in all the environments. In
macOS, the name is not modified.
So we can see the full name "org.webkit.jsc.DFGCompiler".
In Linux, we can see "DFGCompiler", it is quite useful compared to nameless
threads.

What do you think of?

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


Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

2016-12-22 Thread Yusuke SUZUKI
Personally I like the name "SetForScope" since the name "scope" states that
this value change is tied to C++ scope.

On Fri, Dec 23, 2016 at 11:32 JF Bastien  wrote:

> "Scope" seems to capture the C++ nature better.
>
> "Temporary" isn't clear on how long it'll last IMO.
>
>
> On Thu, Dec 22, 2016 at 6:28 PM Saam barati  wrote:
>
> Hi all,
>
> Recently, Yusuke found that JSC and WTF both had the exact same RAII
> helper data structure. JSC called it SetForScope, and WTF called it
> TemporaryChange. (Details here:
> https://bugs.webkit.org/show_bug.cgi?id=164761). Yusuke went to replace
> JSC’s use of SetForScope with TemporaryChange. When I reviewed his patch, I
> suggested to him to rename the class to SetForScope because it was my
> personal preference of the two names. However, I should have first
> discussed this change with other WebKit developers (so I’m doing that now,
> retroactively).
>
> If there is a strong preference to use the name TemporaryChange instead of
> SetForScope, I’ll rename the class back to its original name.
>
> My personal preference is still for the name SetForScope, but my feelings
> are not strongly tied to one name or the other.
>
> - 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] ANN: ES6 Modules are enabled by default

2016-12-20 Thread Yusuke SUZUKI
As of r210016[1], we enabled ES6 modules by default.
We exposed it behind the runtime flag 5 weeks ago and it was shipped in
STP19.
After that, we fixed several minor issues. Now our implementaion passes
all the module related tests in Test262. And the major issues are fixed.

I hope it would become good infrastructure for the other features like HTML
imports. And it would be super nice if we can have great debugging features
for the modules in the inspector.

The next steps are the following,

1. TC39 is working on standardizing dynamic-imports. It gets much attension
and quickly becomes the stage 3 since it is a way to load ES6 modules
on-demand
and this is needed for a long time[2]. It would be good to prototype it on
the top
of our module implementaiton and give feedbacks to the proposal before the
proposal is introduced into the spec.

2. whatwg HTML is also standardizing ES6 modules for the Web Workers. It is
like,
`new Worker("/.js", { type: "module" })`[3]. Worker refactoring done in
[4] will
pave the way for bringing our module loaders into the Web Workers.

3. WebAssembly modules (instance) can be integrated into the module pipeline
once the proposed design is stabilized[5].

If you find any bugs, please file it in bugs.webkit.org and ping me.
And thank you for your support!

[1]: https://trac.webkit.org/changeset/210016
[2]: https://github.com/tc39/proposal-dynamic-import
[3]:
https://html.spec.whatwg.org/multipage/workers.html#module-worker-example
[4]: https://bugs.webkit.org/show_bug.cgi?id=164425
[5]: http://webassembly.org/docs/modules/#integration-with-es6-modules

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


Re: [webkit-dev] Use LayoutTests/resources/ui-helper.js to tap or click an element regardless of platform

2016-12-13 Thread Yusuke SUZUKI
Awesome,

In UIHelper, we heavily use Promises.
I think we can further simplify the test code with async/await.

For example,

UIHelper.wait(async function () {
await UIHelper.activateAt(shadowHost.offsetLeft + 5,
shadowHost.offsetTop + 5);
await UIHelper.activateAt(shadowHost.offsetLeft + 25,
shadowHost.offsetTop + 25);
});

Regards,
Yusuke Suzuki

On Wed, Dec 14, 2016 at 3:55 PM, Ryosuke Niwa <rn...@webkit.org> wrote:

> Hi,
>
> I added a little helper class called UIHelper in https://trac.webkit.org/
> changeset/209780 to provide an abstraction around eventSender and
> UIScriptController so that you can trigger a click or a tap at a specified
> coordinate without having to worry about which platform you’re on.
>
> This is useful if the only thing you’re trying to do is to activate some
> element (e.g. hyperlink, click event handler, etc…) in both DumpRenderTree
> and WebKitTestRunner on both macOS and iOS.
>
> *Background*: iOS WebKit2 port doesn’t have eventSender due to its
> architecture.  As a result, we have UIScriptController which executes
> JavaScript in the UIProcess to trigger key events and touch there.
> However, Mac port’s WebKitTestRunner doesn’t support tap (due to the lack
> of support for touch events).  Furthermore, UIScriptController isn’t
> available in DumpRenderTree on both macOS and iOS.  This makes writing a
> test to activate an element via user interaction that works in
> DumpRenderTree and WebKitTestRunner across macOS and iOS extremely
> challenging.  UIHelper script I added will make this easier by providing an
> abstraction around eventSender and UIScriptController by wrapping those
> internal APIs.
>
> - 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] What happened to WKR and webkitbot?

2016-11-18 Thread Yusuke SUZUKI
Great! Thank you.

Best regards,
Yusuke Suzuki

On Fri, Nov 18, 2016 at 9:09 AM, Lucas Forschler <lforsch...@apple.com>
wrote:

> Hi Yusuke!
> The nightly issue is different, I am escalating a fix now.
>
> Lucas
>
> On Nov 17, 2016, at 11:26 PM, Yusuke SUZUKI <utatane@gmail.com> wrote:
>
> WebKit nightly build is also stopped.
> Is that the same issue?
>
> Regards,
> Yusuke Suzuki
>
> On Thu, Nov 17, 2016 at 10:57 AM, Simon Fraser <simon.fra...@apple.com>
> wrote:
>
>> > On Nov 17, 2016, at 10:21 AM, Osztrogonác Csaba <o...@inf.u-szeged.hu>
>> wrote:
>> >
>> > Hi,
>> >
>> > it seems WKR and webkitbot left #webkit IRC channel
>> > on 4th Nov and we can't see them since then.
>> >
>> > It would be great if somebody could
>> > find and ask them to come back.
>>
>> Top people are working on this. We had to do some network reconfiguring
>> on the hosts that ran these bots.
>>
>> Simon
>>
>> ___
>> 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] What happened to WKR and webkitbot?

2016-11-17 Thread Yusuke SUZUKI
WebKit nightly build is also stopped.
Is that the same issue?

Regards,
Yusuke Suzuki

On Thu, Nov 17, 2016 at 10:57 AM, Simon Fraser <simon.fra...@apple.com>
wrote:

> > On Nov 17, 2016, at 10:21 AM, Osztrogonác Csaba <o...@inf.u-szeged.hu>
> wrote:
> >
> > Hi,
> >
> > it seems WKR and webkitbot left #webkit IRC channel
> > on 4th Nov and we can't see them since then.
> >
> > It would be great if somebody could
> > find and ask them to come back.
>
> Top people are working on this. We had to do some network reconfiguring on
> the hosts that ran these bots.
>
> Simon
>
> ___
> 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 GPU rendering possibility

2016-11-03 Thread Yusuke SUZUKI
I'm not sure it is directly helpful or not. And maybe, I think you already
know that.
But I remember that Cairo has some trace data to test the performance.
And it includes the traces on WebKit.
https://cgit.freedesktop.org/cairo-traces/

Best regards,
Yusuke Suzuki

On Thu, Nov 3, 2016 at 12:42 PM, Myles C. Maxfield <mmaxfi...@apple.com>
wrote:

>
> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>
>
>
> 03.11.2016, 22:18, "Rogovin, Kevin" <kevin.rogo...@intel.com>:
>
> Hi,
>
>  What are some good 2D UI graphics benchmarks that are cross-platform-ish?
> I'd think I need to port them to Fast UI Draw, but that is possible.
>
>  I am very confident that Fast UI Draw will perform at the top by a large
> margin. The more complicated and heavier the load, the better it will do.
>
>
> I would suggest you to do prototype implementation of GraphicsContext
> (e.g. by replacing code in GraphicsContextCairo) and run those browser
> performance benchmarks. If there is substantial improvement, there will be
> community enthusiasm.
>
>
> As Konstantin says, browser-based benchmarks would be best, but I assumed
> you didn’t want to implement GraphicsContext before running benchmarks. If
> you do implement GraphicsContext in a branch of WebKit, there are a few
> browser-based performance tests which may be insightful:
>
>- CanvasMark http://www.kevs3d.co.uk/dev/canvasmark/
>- Mozilla has a list of benchmarks https://wiki.mozilla.org/Benchmarks
>- Canvas Performance Test http://www.smashcat.org/av/canvas_test/
>
> Perhaps some of these could even be ported to native code so you could get
> up and running sooner.
>
> —Myles
>
>
> -Kevin
>
> -Original Message-
> From: mmaxfi...@apple.com [mailto:mmaxfi...@apple.com
> <mmaxfi...@apple.com>]
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin <kevin.rogo...@intel.com>
> Cc: Carlos Garcia Campos <carlo...@webkit.org>;
> webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
> It sounds like the primary focus of your work is improving performance. It
> also sounds like the only benchmark you’ve run is an artificial one that
> you constructed yourself.
>
> Given these two things, I would strongly hesitate to call our interest
> "significant community enthusiasm.”
>
> Why don’t you start by running some of the many existing graphics
> benchmarks with your library?
>
> Please correct me if my assumptions are mistaken.
>
> Thanks,
> Myles
>
>  On Nov 3, 2016, at 12:50 AM, Rogovin, Kevin <kevin.rogo...@intel.com>
> wrote:
>
>  Adding a new GraphicsContext is what I want to do as it seems the path of
> least pain and suffering. However, all the other things of a backend I do
> not need to do. I do not know how to add a GraphicsContext backend in terms
> of makefile magicks and configuration. I also do not know the plumbing for
> making it active. In theory, FastUIDraw's GraphicsContext will work on any
> platform that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do
> this? Years ago I remember that the build configuration is what governed
> what backend was built... and I usually just piggy packed onto another...
> years ago I remember there was like an SDL style backend that did not
> require a large toolkit, just SDL.. is that still alive? where is it? I
> could piggy back the work there if it still is alive...
>
>  Also, to get permission to do this work, I need significant community
> enthusiasm otherwise I will not be able to justify the large amount of work
> needed. This is another area where I need a great deal of help.
>
>  Best Regards,
>  -Kevin Rogovin
>
>  -Original Message-
>  From: Carlos Garcia Campos [mailto:carlo...@webkit.org
> <carlo...@webkit.org>]
>  Sent: Thursday, November 3, 2016 9:43 AM
>  To: Rogovin, Kevin <kevin.rogo...@intel.com>; Myles C. Maxfield
>  <mmaxfi...@apple.com>
>  Cc: webkit-dev@lists.webkit.org
>  Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
>  El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
>
>  Hi,
>
>   The main issue of making a Cairo backend to FastUIDraw is clipping.
>  Cairo tracks the clipping region in CPU and does things that are fine
>  for CPU-based rendering (i.e. span based rendering) but are
>  absolutely awful for GPU rendering (from my slides, one sees that GL
>  backed QPainter and Cairo do much worse than CPU backed). FastUIDraw
>  only supports clipIn and clipOut and pushes all the clipping work to
>  the GPU with almost no CPU work. It does NOT track the clipping
>  region at all. I can g

Re: [webkit-dev] Are there any plans to upgrade SVN server on svn.webkit.org?

2016-06-19 Thread Yusuke SUZUKI
Great work, thanks.

I've just noticed that the ToT git revision in git://
git.webkit.org/WebKit.git is r202198 while ToT SVN revision is r202223.

On Mon, Jun 20, 2016 at 3:30 AM, Lucas Forschler 
wrote:

> svn.webkit.org is back online.
> Please let me know if you see any problems.
>
> I will be doing minor additional maintenance later this week. I do not
> expect the downtime to be nearly as significant as this upgrade. I’ll send
> email with advance notice of additional downtime.
> Lucas
>
>
> On Jun 18, 2016, at 10:51 PM, Lucas Forschler 
> wrote:
>
> Update: The svn data migration to the new format is currently about 1/3 of
> the way completed. I’ll post another progress update Sunday morning
> (Pacific time zone).
> Thanks,
> Lucas
>
>
> On Jun 18, 2016, at 5:14 PM, Lucas Forschler  wrote:
>
> I’m starting this now. svn.webkit and build.webkit will be going down
> shortly.
> I’ll send an all-clear email when things are back online.
>
> Lucas
>
> On Jun 18, 2016, at 9:54 AM, Lucas Forschler  wrote:
>
> Hello Folks,
>
> I plan on updating the svn repository from version 1.6.11 to 1.9.4
> tonight. I will likely start this process sometime this late afternoon.
> svn.webkit.org will be down during this time. I will also be taking
> build.webkit.org offline, so our bots do not fail due to a missing svn
> server.
>
> I will also be taking this time to upgrade the backend datastore on
> svn.webkit.org. This process requires a full svn dump/load cycle, and
> takes a significant amount of time. I expect the the server to return
> online Sunday by end of day.
>
> Please let me know if you have any questions.
> I’ll send another email before I take the servers offline.
> Lucas
>
>
> On Apr 27, 2016, at 5:13 AM, Konstantin Tokarev  wrote:
>
> Hello,
>
> According to [1], currently svn.webkit.org runs severely outdated
> Subversion 1.6.11. Since then, there were 3 significant releases of
> Subversion, which brought lots of performance improvements, most
> importantly brand new HTTP protocol [3] and storage format improvements
> [4]. Also, since 1.7 Apache 2.4 with MPM event is supported, which may
> increase server throughput.
>
>
> BTW, to improve performance of up to date Subversion client (>= 1.8), it
> is needed to adjust Apache configuration[5]: increase MaxKeepAliveRequests
> from default 100 to at least 1000. This needs to be done regardless of
> Subversion server upgrade.
>
>
> [1] http://svn.webkit.org/repository/webkit/
> [2] https://subversion.apache.org/docs/release-notes/1.7.html
> https://subversion.apache.org/docs/release-notes/1.8.html
> https://subversion.apache.org/docs/release-notes/1.9.html
> [3] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2
> [4]
> https://subversion.apache.org/docs/release-notes/1.8.html#fsfs-enhancements
>
> https://subversion.apache.org/docs/release-notes/1.9.html#fsfs-improvements
> [5] https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
>http://svn.haxx.se/dev/archive-2011-01/0320.shtml
>
> --
> Regards,
> Konstantin
> ___
> 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


Re: [webkit-dev] [ANN] JSCOnly port becomes dependency-free (except for ICU)

2016-04-21 Thread Yusuke SUZUKI
On Thu, Apr 21, 2016 at 3:12 AM, Eric Wing <ewmail...@gmail.com> wrote:

> On 4/18/16, Yusuke SUZUKI <utatane@gmail.com> wrote:
> > Hi folks,
> >
> > Thanks to Konstantin Tokavev and GTK guys, JSCOnly port becomes quickly
> > mature.
> > As of now, finally, JSCOnly port becomes completely dependency free port
> > (except for ICU :P).
> > It means that, when you need some Linux JSC shell to test, you just
> >
> > 1. clone the tree
> > 2. install ICU (sudo apt-get install libicu-dev)
> > 3. hit `Tools/Scripts/build-webkit --jsc-only`
> >
> > That's it! After building, you will get the JSC shell on (almost) any
> > platforms and you also get the TestWTF.
> > It makes easy to build / contribute to JSC.
> > And it makes building old (from now) JSC easy, it's super beneficial.
> > For example, when you encounter the performance regression in some
> revision
> > XXX, previously, you need to,
> >
> > 1. checkout the old rev
> > 2. prepare the old dependencies (Let's build old DependenciesXXX!)
> > 3. let's build the JSC and check the regression
> >
> > But now, we can just checkout the old revision and build the old JSC.
> >
> > Best regards,
> > Yusuke Suzuki
> >
>
>
> Just curious, is this expected to work for Windows/Visual Studio too?
>

If you build it with CMake, it should work fine I think (And if it cannot
be done, it's a bug, plz file it.)


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


[webkit-dev] [ANN] JSCOnly port becomes dependency-free (except for ICU)

2016-04-18 Thread Yusuke SUZUKI
Hi folks,

Thanks to Konstantin Tokavev and GTK guys, JSCOnly port becomes quickly
mature.
As of now, finally, JSCOnly port becomes completely dependency free port
(except for ICU :P).
It means that, when you need some Linux JSC shell to test, you just

1. clone the tree
2. install ICU (sudo apt-get install libicu-dev)
3. hit `Tools/Scripts/build-webkit --jsc-only`

That's it! After building, you will get the JSC shell on (almost) any
platforms and you also get the TestWTF.
It makes easy to build / contribute to JSC.
And it makes building old (from now) JSC easy, it's super beneficial.
For example, when you encounter the performance regression in some revision
XXX, previously, you need to,

1. checkout the old rev
2. prepare the old dependencies (Let's build old DependenciesXXX!)
3. let's build the JSC and check the regression

But now, we can just checkout the old revision and build the old JSC.

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


Re: [webkit-dev] Keith Miller is now a WebKit reviewer

2016-04-05 Thread Yusuke SUZUKI
Congrats :D

---
Regards,
Yusuke Suzuki

On Wed, Apr 6, 2016 at 5:11 AM, Saam Barati <sbar...@apple.com> wrote:

> Congrats!
>
> Saam
>
> > On Apr 5, 2016, at 12:32 PM, Mark Lam <mark@apple.com> wrote:
> >
> > Hi everyone,
> >
> > Just want to announce that Keith Miller is now a reviewer.  Keith
> primarily works on JavaScriptCore.  Feel free to ask him for reviews.
> >
> > Congratulations, Keith.
> >
> > 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] Sukolsak Sakshuwong is now a WebKit Reviewer

2016-03-08 Thread Yusuke SUZUKI
Congrats!

---
Regards,
Yusuke Suzuki

On Wed, Mar 9, 2016 at 6:01 AM, Ryosuke Niwa <rn...@webkit.org> wrote:

> Congratulations, Sukolsak!
>
> - R. Niwa
>
> On Tue, Mar 8, 2016 at 11:33 AM, Mark Lam <mark@apple.com> wrote:
>
>> Hi everyone,
>>
>> Just want to announce that Sukolsak Sakshuwong is now a reviewer.
>> Congratulations, Sukolsak.
>>
>> 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] JSCOnly port

2016-02-21 Thread Yusuke SUZUKI
And, now, I'm setting up a VPS server for the buildbot...

---
Regards,
Yusuke Suzuki

On Sun, Feb 21, 2016 at 11:14 PM, Yusuke SUZUKI <utatane@gmail.com>
wrote:

> If the name "JSCOnly" is accepted by WebKittens, I'll set r+ for that
> patch :)
> The other part looks good for the first step!
>
> Regards,
> Yusuke Suzuki
>
> On Sun, Feb 21, 2016 at 10:50 PM, Konstantin Tokarev <annu...@yandex.ru>
> wrote:
>
>>
>>
>> 21.02.2016, 16:45, "Yusuke SUZUKI" <utatane@gmail.com>:
>> > +1. Looks nice to me :)
>> > Now, B3 is working on Linux, we can drop LLVM dependencies while
>> enabling aggressive JIT compilers (enabling LLInt, Baseline, DFG, FTL_B3).
>> > So, only the dependent library for JSCOnly port is ICU, that is
>> desireble.
>>
>> BTW, reportedly B3 works on Win64 (run-layout-jsc passes 634 tests of 646)
>>
>> >
>> > Regards,
>> > Yusuke Suzuki
>> >
>> > On Sun, Feb 21, 2016 at 10:41 PM, Konstantin Tokarev <annu...@yandex.ru>
>> wrote:
>> >> Hello,
>> >>
>> >> Following the discussion in "Thought about Nix JavaScriptCore port",
>> I'm proposing patch [1] that adds new port named "JSCOnly". It is based on
>> patch proposed by Yusuke Suzuki in [2], where you can also find
>> justification.
>> >>
>> >> As the name suggests, this port builds only JSC library and
>> executable, and has no external dependencies besides ICU. This port can be
>> easily enhanced to support building on Windows, therefore it's no longer
>> called "Nix".
>> >>
>> >> If this patch is accepted I would like to set up build slave for
>> Linux/MIPS using this port.
>> >>
>> >> [1] https://bugs.webkit.org/show_bug.cgi?id=154512
>> >> [2]
>> https://lists.webkit.org/pipermail/webkit-dev/2015-November/027785.html
>> >>
>> >> --
>> >> Regards,
>> >> Konstantin
>>
>>
>> --
>> Regards,
>> Konstantin
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


  1   2   >