Re: [webkit-dev] Introducing brand new EWS

[Ryosuke Niwa]

Yes, that would be great.

Although I'd still prefer having a proper waterfall view so that when my
patch isn't getting processed / very behind in the queue, I can figure out
what's causing it on my own instead of having to tell a bot watcher
something is wrong with EWS.

- R. Niwa

On Thu, Apr 11, 2019 at 12:17 PM Aakash Jain  wrote:

> Hi Ryosuke,
>
> Sorry for the delay. I will soon be adding the feature to display patch's
> position in queue in https://bugs.webkit.org/show_bug.cgi?id=196607.
> Would that address your concern?
>
> Thanks
> Aakash
>
> On Apr 4, 2019, at 10:09 PM, Ryosuke Niwa  wrote:
>
> The new bubbles seem to be working well, and having API tests running in
> EWS is great!
>
> Can we add the waterfall view to https://ews-build.webkit.org/#/builders so
> that we can see where our patches are in the queue?
>
> - R. Niwa
>
> On Thu, Apr 4, 2019 at 6:59 PM Aakash Jain  wrote:
>
>> Introducing brand new EWS
>>
>> with EWS for API Tests (for macOS and iOS)
>>
>> and EWS for WebKitPerl Tests!
>>
>>
>> Starting today, when you upload a patch to bugs.webkit.org, you will see
>> few more bubbles (for API tests and webkitperl tests). You might also see
>> additional button 'Submit to new EWS' (if the patch doesn't have r? flag).
>>
>> The new EWS comes with many new features and there are lot more I want to
>> add. But, I don't want you guys to wait more to start getting the benefits.
>> That's why I am rolling it out in phases, starting with EWS for API Tests
>> and WebKitPerl Tests. These are tests which are not currently covered by
>> the existing EWS. Next step would be to move queues from existing EWS to
>> new EWS one by one, with the eventual goal of moving over everything to new
>> EWS.
>>
>>
>> *Why new EWS?*
>> The existing EWS has certain architectural limitations. One of the
>> prominent limitation is that there is no concept of building and testing
>> the patch on different queues. If we have three queues: WK1 tests, WK2
>> tests and API tests, all three queues would need to compile WebKit
>> independently. So WebKit would be compiled thrice instead of once. This is
>> inefficient and thereby require more hardware.
>>
>> The new EWS has separate builder and tester queues. Builder queues build
>> once and upload the archive. Multiple tester queues download that same
>> archive and run tests on that. That way WebKit is compiled only once, and
>> re-used on multiple tester queues. This improves system efficiency and
>> allows us to add new test queues with substantially less hardware.
>>
>> The new EWS uses Buildbot at the back-end, which is a production-level CI
>> system. It is easier to maintain and automatically provide various features
>> like historical build logs, real-time log streaming, easier bot management,
>> ability to retry a build etc. Plus, it’s a system most of you are already
>> familiar with (build.webkit.org).
>>
>>
>> *How can you contribute:*
>> If you are interested in contributing, the source code is located at:
>> ews-build (Buildbot): Tools/BuildSlaveSupport/ews-build
>> ews-app (web-app): Tools/BuildSlaveSupport/ews-app
>>
>> Detailed instructions are at:
>> https://trac.webkit.org/wiki/EarlyWarningSystem#ContributingtoEarlyWarningSystem
>>
>>
>> *Upcoming features:*
>> - status-bubble should display position in queue
>> https://bugs.webkit.org/show_bug.cgi?id=196607
>> - EWS should comment on Bugzilla bugs about failures
>> https://bugs.webkit.org/show_bug.cgi?id=196598
>> - EWS should have a way to retry a patch
>> https://bugs.webkit.org/show_bug.cgi?id=196599
>> - Security EWS https://bugs.webkit.org/show_bug.cgi?id=196605
>>
>>
>> If you notice any issue, please feel free to file bugs (and assign to me).
>>
>> Thanks & Regards
>> Aakash Jain
>> ___
>> 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] Introducing brand new EWS

[Aakash Jain]

Hi Ryosuke,

Sorry for the delay. I will soon be adding the feature to display patch's 
position in queue in https://bugs.webkit.org/show_bug.cgi?id=196607 
. Would that address your 
concern?

Thanks
Aakash

> On Apr 4, 2019, at 10:09 PM, Ryosuke Niwa  wrote:
> 
> The new bubbles seem to be working well, and having API tests running in EWS 
> is great!
> 
> Can we add the waterfall view to https://ews-build.webkit.org/#/builders 
>  so that we can see where our 
> patches are in the queue?
> 
> - R. Niwa
> 
> On Thu, Apr 4, 2019 at 6:59 PM Aakash Jain  > wrote:
> Introducing brand new EWS
> 
> with EWS for API Tests (for macOS and iOS)
> 
> and EWS for WebKitPerl Tests!
> 
> 
> Starting today, when you upload a patch to bugs.webkit.org 
> , you will see few more bubbles (for API tests and 
> webkitperl tests). You might also see additional button 'Submit to new EWS' 
> (if the patch doesn't have r? flag).
> 
> The new EWS comes with many new features and there are lot more I want to 
> add. But, I don't want you guys to wait more to start getting the benefits. 
> That's why I am rolling it out in phases, starting with EWS for API Tests and 
> WebKitPerl Tests. These are tests which are not currently covered by the 
> existing EWS. Next step would be to move queues from existing EWS to new EWS 
> one by one, with the eventual goal of moving over everything to new EWS.
> 
> 
> Why new EWS?
> The existing EWS has certain architectural limitations. One of the prominent 
> limitation is that there is no concept of building and testing the patch on 
> different queues. If we have three queues: WK1 tests, WK2 tests and API 
> tests, all three queues would need to compile WebKit independently. So WebKit 
> would be compiled thrice instead of once. This is inefficient and thereby 
> require more hardware.
> 
> The new EWS has separate builder and tester queues. Builder queues build once 
> and upload the archive. Multiple tester queues download that same archive and 
> run tests on that. That way WebKit is compiled only once, and re-used on 
> multiple tester queues. This improves system efficiency and allows us to add 
> new test queues with substantially less hardware.
> 
> The new EWS uses Buildbot at the back-end, which is a production-level CI 
> system. It is easier to maintain and automatically provide various features 
> like historical build logs, real-time log streaming, easier bot management, 
> ability to retry a build etc. Plus, it’s a system most of you are already 
> familiar with (build.webkit.org ).
> 
> 
> How can you contribute:
> If you are interested in contributing, the source code is located at:
> ews-build (Buildbot): Tools/BuildSlaveSupport/ews-build
> ews-app (web-app): Tools/BuildSlaveSupport/ews-app
> 
> Detailed instructions are at: 
> https://trac.webkit.org/wiki/EarlyWarningSystem#ContributingtoEarlyWarningSystem
>  
> 
> 
> 
> Upcoming features:
> - status-bubble should display position in queue 
> https://bugs.webkit.org/show_bug.cgi?id=196607 
> 
> - EWS should comment on Bugzilla bugs about failures 
> https://bugs.webkit.org/show_bug.cgi?id=196598 
> 
> - EWS should have a way to retry a patch 
> https://bugs.webkit.org/show_bug.cgi?id=196599 
> 
> - Security EWS https://bugs.webkit.org/show_bug.cgi?id=196605 
> 
> 
> 
> If you notice any issue, please feel free to file bugs (and assign to me).
> 
> Thanks & Regards
> Aakash Jain
> ___
> 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] Concurrent JS and 32bit platforms

[Filip Pizlo]

> On Apr 11, 2019, at 7:03 AM, Xan  wrote:
> 
> Hi all,
> 
> as part of our work on improving 32bit support in JSC we at Igalia are 
> planning to have a look at enabling concurrent js

We don’t support concurrent JavaScript. 

We do have concurrent JITs and concurrent GC. 

> for these platforms. Before we dive in, though, we thought it would be better 
> to ask some preliminary questions:
> 
> - Was this feature only implemented for 64bit because that was the focus of 
> the implementors moving forward? Or is there any fundamental difficulty in 
> the current architecture? In particular we have seen some comments about 
> atomic updates of JSValues that suggest it could be hard (or impossible) to 
> get this done on 32bit with the current approach.

Can’t do atomic access to JSValues on 32-bit. That’s a showstopper. 

> 
> - Assuming this is doable right now, we'll get on with it. Assuming it's not: 
> would you be open to making the necessary changes to JSC to make concurrent 
> js an option on 32bits?

No. 

-Filip

> 
> Thanks,
> 
> Xan
> ___
> 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] Concurrent JS and 32bit platforms

[Konstantin Tokarev]

11.04.2019, 17:03, "Xan" :
> Hi all,
>
> as part of our work on improving 32bit support in JSC we at Igalia are 
> planning to have a look at enabling concurrent js for these platforms. Before 
> we dive in, though, we thought it would be better to ask some preliminary 
> questions:
>
> - Was this feature only implemented for 64bit because that was the focus of 
> the implementors moving forward? Or is there any fundamental difficulty in 
> the current architecture? In particular we have seen some comments about 
> atomic updates of JSValues that suggest it could be hard (or impossible) to 
> get this done on 32bit with the current approach.
>
> - Assuming this is doable right now, we'll get on with it. Assuming it's not: 
> would you be open to making the necessary changes to JSC to make concurrent 
> js an option on 32bits?

This feature would be very much appreciated, there are lots of multicore 
embedded Linux systems which have to use 32-bit userspace


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

[webkit-dev] Concurrent JS and 32bit platforms

[Xan]

Hi all,

as part of our work on improving 32bit support in JSC we at Igalia are
planning to have a look at enabling concurrent js for these platforms.
Before we dive in, though, we thought it would be better to ask some
preliminary questions:

- Was this feature only implemented for 64bit because that was the focus of
the implementors moving forward? Or is there any fundamental difficulty in
the current architecture? In particular we have seen some comments about
atomic updates of JSValues that suggest it could be hard (or impossible) to
get this done on 32bit with the current approach.

- Assuming this is doable right now, we'll get on with it. Assuming it's
not: would you be open to making the necessary changes to JSC to make
concurrent js an option on 32bits?

Thanks,

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