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

[Olmstead, Don]

We’re fine with removing it.

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


On Dec 5, 2017, at 11:19 AM, Michael Saboff 
> wrote:

Here is the reply from iTunes for the WebKit-Dev list

- Michael

——

From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber 
API support.

iTunes still uses some cooperative threading, but implements its own mechanism 
on top of regular preemptive Windows threads. And we believe we've fixed all 
occurrences of calling WebKit/JSC from our non-main cooperative threads.

- John


On Dec 5, 2017, at 10:26 AM, Michael Saboff 
> wrote:

[Bringing John Lehner from the iTunes team into the discussion]

Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
into WebKit/JSC only has one fiber, other parts of the app use multiple fibers 
on one thread but don’t have JS objects active in those threads / fibers.

John, have things changed for iTunes on Windows such that we can eliminate 
support for fibers?

- Michael


On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa 
> wrote:

Yeah, I don't think there is much need to support fibers. With features like 
web workers, supporting fibers doesn't make much sense.

- R. Niwa

On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI 
> wrote:
Hi, Webkittens,

I would like to make sure OR declare that WebKit does not support Windows 
fibers.
While fiber related functions are used in WTF, I believe that it is because 
fiber local storage (FLS) can have destructors. And it is not intended to 
support fibers explicitly.

Actually, I believe the current WebKit does not work well with Windows fibers 
right now.
For example, our JSC GC is conservative for stack and registers. It means that 
GC needs to scan stack and registers to gather conservative roots. But if your 
fiber is not executed at that time, JSC GC will miss to scan the stack and 
registers of those inactive fibers. As a result, managed objects will be 
collected if it is only referenced from the roots in the inactive fibers.

And I think we can potentially improve performance of our TLS by using 
thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
causes some problems[1]. I'm not sure the performance characteristics and 
implementation details of thread_local in VC++, but it's worth checking.

So, I think we should not support Windows fibers. I would like to hear opinions 
about it.

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

Best regards,
Yusuke Suzuki

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

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

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

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

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

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

[Geoffrey Garen]

If our Windows clients are cool with it, I think we should remove support for 
fibers.

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

Geoff

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

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

Re: [webkit-dev] WinCairo Build and EWS down

[Olmstead, Don]

EWS and Buildbots are back up for WinCairo and are successfully building. If 
there are any problems let me know! Apologies for the downtime.

From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Olmstead, Don
Sent: Friday, December 1, 2017 5:32 PM
To: WebKit-Dev Development (webkit-dev@lists.webkit.org) 

Subject: [webkit-dev] WinCairo Build and EWS down

Hi WebKittens,

We're having an issue with the Buildbot and EWS after the ANGLE update. Our 
image does not contain the DirectX 11 SDK that is now wanted by ANGLE. I spent 
my day trying to get the required SDK into the image and have been having 
issues with it so I was not able to spin up the infrastructure again.

I'll get it back as soon as I can but for the moment feel free to ignore any 
WinCairo EWS issues. I'll hopefully have things fixed early next week and let 
the group know.

Thanks
Don
___
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

[Michael Saboff]

Here is the reply from iTunes for the WebKit-Dev list

- Michael

——

From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber 
API support.

iTunes still uses some cooperative threading, but implements its own mechanism 
on top of regular preemptive Windows threads. And we believe we've fixed all 
occurrences of calling WebKit/JSC from our non-main cooperative threads.

- John

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

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

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

[Michael Saboff]

[Bringing John Lehner from the iTunes team into the discussion]

Last I knew, the iTunes team uses fibers.  IIRC, the thread they use to call 
into WebKit/JSC only has one fiber, other parts of the app use multiple fibers 
on one thread but don’t have JS objects active in those threads / fibers.

John, have things changed for iTunes on Windows such that we can eliminate 
support for fibers?

- Michael

> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa  wrote:
> 
> Yeah, I don't think there is much need to support fibers. With features like 
> web workers, supporting fibers doesn't make much sense.
> 
> - R. Niwa
> 
> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI  > wrote:
> Hi, Webkittens,
> 
> I would like to make sure OR declare that WebKit does not support Windows 
> fibers.
> While fiber related functions are used in WTF, I believe that it is because 
> fiber local storage (FLS) can have destructors. And it is not intended to 
> support fibers explicitly.
> 
> Actually, I believe the current WebKit does not work well with Windows fibers 
> right now.
> For example, our JSC GC is conservative for stack and registers. It means 
> that GC needs to scan stack and registers to gather conservative roots. But 
> if your fiber is not executed at that time, JSC GC will miss to scan the 
> stack and registers of those inactive fibers. As a result, managed objects 
> will be collected if it is only referenced from the roots in the inactive 
> fibers.
> 
> And I think we can potentially improve performance of our TLS by using 
> thread_local implementation in VC++ instead of using FLS. FLS is slow and it 
> causes some problems[1]. I'm not sure the performance characteristics and 
> implementation details of thread_local in VC++, but it's worth checking.
> 
> So, I think we should not support Windows fibers. I would like to hear 
> opinions about it.
> 
> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 
> 
> 
> Best regards,
> Yusuke Suzuki
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Ryosuke Niwa]

Yeah, I don't think there is much need to support fibers. With features
like web workers, supporting fibers doesn't make much sense.

- R. Niwa

On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI  wrote:

> Hi, Webkittens,
>
> I would like to make sure OR declare that WebKit does not support Windows
> fibers.
> While fiber related functions are used in WTF, I believe that it is
> because fiber local storage (FLS) can have destructors. And it is not
> intended to support fibers explicitly.
>
> Actually, I believe the current WebKit does not work well with Windows
> fibers right now.
> For example, our JSC GC is conservative for stack and registers. It means
> that GC needs to scan stack and registers to gather conservative roots. But
> if your fiber is not executed at that time, JSC GC will miss to scan the
> stack and registers of those inactive fibers. As a result, managed objects
> will be collected if it is only referenced from the roots in the inactive
> fibers.
>
> And I think we can potentially improve performance of our TLS by using
> thread_local implementation in VC++ instead of using FLS. FLS is slow and
> it causes some problems[1]. I'm not sure the performance characteristics
> and implementation details of thread_local in VC++, but it's worth checking.
>
> So, I think we should not support Windows fibers. I would like to hear
> opinions about it.
>
> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448
>
> Best regards,
> Yusuke Suzuki
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Yusuke SUZUKI]

Hi, Webkittens,

I would like to make sure OR declare that WebKit does not support Windows
fibers.
While fiber related functions are used in WTF, I believe that it is because
fiber local storage (FLS) can have destructors. And it is not intended to
support fibers explicitly.

Actually, I believe the current WebKit does not work well with Windows
fibers right now.
For example, our JSC GC is conservative for stack and registers. It means
that GC needs to scan stack and registers to gather conservative roots. But
if your fiber is not executed at that time, JSC GC will miss to scan the
stack and registers of those inactive fibers. As a result, managed objects
will be collected if it is only referenced from the roots in the inactive
fibers.

And I think we can potentially improve performance of our TLS by using
thread_local implementation in VC++ instead of using FLS. FLS is slow and
it causes some problems[1]. I'm not sure the performance characteristics
and implementation details of thread_local in VC++, but it's worth checking.

So, I think we should not support Windows fibers. I would like to hear
opinions about it.

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

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