September 2019 - webkit-dev - lists.webkit.org

WinCairo EWS
by Alex Christensen 02 Oct '19

02 Oct '19

The WinCairo EWS bot has been in pretty sad shape for a while, providing no useful information and lots of false negatives. Could someone please fix it or remove it? See https://ews-build.webkit.org/#/builders/12/builds/5501 <https://ews-build.webkit.org/#/builders/12/builds/5501> for an example.

4 3

ios-wk2 EWS in a bad state because of flaky tests
by Aakash Jain 30 Sep '19

30 Sep '19

Hi All, Last week we updated the iOS bots from iOS 12 to iOS 13. Since then we have been noticing a lot of flaky tests. Because of that ios-wk2 queue has been in a bad state. Most of the time, it is unable to determine if the test failures were introduced by the patch or were pre-existing, and so it keep re-testing the patch. Because of this various patches keep waiting for long time. Me and few bot watchers are looking into these flaky failures, but it might take a while to get the queue back to a good state. Meanwhile, if anyone of you has any recent bugs assigned to you related to flaky tests, it would be nice to prioritize that. Thanks Aakash

1 1

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?
by Emilio Cobos Álvarez 29 Sep '19

29 Sep '19

On 9/29/19 5:07 AM, Rick Byers wrote: > On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez > <emilio(a)mozilla.com <mailto:emilio@mozilla.com>> wrote: > > Hi Steve, > > On 9/27/19 4:03 PM, Steve Kobes wrote: > > Hi Emilio, > > > > My recollection is that scroll anchoring was, in fact, a mess. I > do not > > personally have any opinion about whether scroll anchoring should be > > removed from Gecko. > > > > We (Chrome) decided to accept some compat issues for the sake of > > launching the feature. This was a judgment call and could > reasonably > > have gone the other way. > > Right, my concern is that taking compat fallout with Chrome's market > share may be acceptable, because people will likely fix their websites > if they misbehave. > > But web developers may not take the same time to fix their site if it's > broken on Firefox for Android, for example, which in turn drives > Firefox > users away (and you know this is a vicious cycle, the less users you > have, the less people will care about fixing their websites in your > browser). > > That being said, more generally, I care about being interoperable / > predictable here for web developers, and seems like that ship may have > sailed if we need to fix some Gecko-specific issues by tweaking our > heuristics, but Chromium / Blink doesn't change them in the same way > (which is understandable, I guess, though I've filed spec issues for > our > reasoning behind these changes, which I think would apply to Chrome as > well). > > > FWIW, I agree with this principle. I'm sorry you've had to do a lot of > compat work on this Emilio. Are you saying you've found many cases where > chromium's behavior doesn't match the spec / web-platform-tests and the > different is relevant to real-world website compat (forcing you to > invest in "bug-for-bug compatibility")? That would definitely make me > very sad. Or is the issue more about compat with sites which have > UA-conditional behavior (either explicit or implicit based on some other > Gecko/blink difference?). Well, part of it is that. The initial implementation took a lot of just figuring out what Chromium was doing rather than implementing the spec, because the spec had clear issues (like referencing the DOM rather than layout stuff). Some of them like [1] were pretty obvious and were caught during our initial implementation of the feature. Others like [2] Ryan probably found by testing Chromium's behavior. Some other still pretty significant behavior differences were only caught later by me and people finding compat issues in the wild, like [3]. I was sad that the spec reflected absolutely nothing like what Blink implements. For this issue in particular, Blink roughly uses "whatever inherits from LayoutBox can be an anchor", which is obviously not something that you can reasonably spec, and definitely not "block boxes and text", which is what the spec said. Those are off the top of my head, Ryan probably has more examples. > IMHO In general, either an initially chromium-only feature is valuable > enough that we should continue to invest as necessary to achieve interop > with other engines when they implement (eg. adding web-platform-tests > and improving the spec for the inevitable cases that appear with a > second implementation), or we should decide the feature isn't worth the > cost to properly support on the web at large and remove it from chromium. > > Steve is the expert and can probably elaborate on details, but IIRC the > real world web compat constraints of scroll anchoring ended up requiring > a number of tough tradeoffs. If you're learning about new web compat > constraints, then it's entirely possible that the cost/benefit equation > is now different and we should be re-evaluating whether it still makes > sense to keep scroll anchoring in chromium. Like David I like the > feature - but only to the extent that it works alright for most of the > web as it exists today, and developers can reliably reason about it (eg. > by replacing any heuristics designed under the constraints of web-compat > with explicit APIs). > > Can you give us a week or so to chat about this within the Chrome team > and get back to you? > > Thanks, and sorry again for the frustration. When we ship a feature > first in chromium, it's always our intent that subsequent compatible > implementations should be MUCH easier to ship (it's one of the main > reasons we invest so much in web-platform-tests). Sure, no worries, and thanks for the reply. -- Emilio [1]: https://github.com/w3c/csswg-drafts/issues/3480 [2]: https://github.com/w3c/csswg-drafts/issues/3319 [3]: https://github.com/w3c/csswg-drafts/issues/4247 > -- Emilio > > > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez > <emilio(a)mozilla.com <mailto:emilio@mozilla.com> > > <mailto:emilio@mozilla.com <mailto:emilio@mozilla.com>>> wrote: > > > > And, to be clear, we _can_ fix these compat issues, some way > or another. > > > > One thought is to limit the amount of scroll adjustments > without user > > scrolling or stuff like that, which would prevent the "you > get stuck on > > the page". > > > > Making anchoring opt-in rather than opt-out is another > option, but that > > defeats most of the purpose of the feature, I guess. > > > > See also some of the Chromium docs on the compat issues they > found[1] > > and how were they trying to fix them before adding the > > "layout-affecting-property changed" heuristic, which is what > is on the > > spec right now and what they implement. > > > > I just think that these are very hacky heuristics that are just > > going to > > bring a lot of compat pain and developer confusion. > > > > It doesn't help that all these things can break or not > depending on the > > speed at which the user scrolls, the amount of scroll events > that the > > user dispatches, the timing of these events relative to other > > events, etc... > > > > -- Emilio > > > > [1]: > > > https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3N… > <https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3N…> > > > <https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3N… <https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3N…>> > > > > On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote: > > > Hi, > > > > > > (cc'ing webkit-dev@ and blink-dev@ in case they have > feedback or > > > opinions, as WebKit is the only engine which does not > implement > > scroll > > > anchoring, though I don't know if they plan to, and Blink > is the > > only > > > other engine that does implement it. Please reply to > > dev-platform@ though.) > > > > > > TLDR: Scroll anchoring is really a mess. > > > > > > I didn't do the initial implementation of the feature in > Gecko, > > but I've > > > done a ton of work over the last few months to fix compat > issues > > in our > > > implementation (see all the bugs blocking [1]). > > > > > > At this point, our implementation is mostly compatible with > > Blink, but > > > even with a bug-for-bug compatible implementation, we did > get compat > > > issues because of different content being served for different > > browsers, > > > or because our anti-tracking protections changing the final > > content of > > > the page slightly ([2] is an example of bug which only > reproduces > > with > > > ETP enabled only, but whose reduced test-case renders the site > > unusable > > > in Chrome as well). > > > > > > If you hit one of the broken cases as a user you think the > > browser is > > > completely broken, and the site is just unusable. > > > > > > I've fixed those by tweaking the heuristics Gecko uses. > Those extra > > > heuristics have also caused other compat issues, like [3], > reported > > > today, which will require other adjustments to the > heuristics, etc... > > > > > > On top of that, the spec is not in a good state, with ton > of open > > issues > > > without feedback from the editors [4]. > > > > > > So right now I'm at a stage where I think that the feature is > > just not > > > worth it. It doesn't behave predictably enough for developers, > > and you > > > have no guarantee of it behaving consistently unless you > test a > > > particular browser, with a particular content in a particular > > viewport > > > size... That's not great given the current dominant > position of > > > Chromium-based browsers. > > > > > > On top, issues with scroll anchoring are pretty hard to > diagnose > > unless > > > you're aware of the feature. > > > > > > All in all, it doesn't seem like the kind of feature that > benefits a > > > diverse web (nor web developers for that matter), and I > think we > > should > > > remove the feature from Gecko. > > > > > > Does anyone have strong opinions against removing scroll > > anchoring from > > > Gecko, based on the above? > > > > > > Thanks, > > > > > > -- Emilio > > > > > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1519644> > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1519644 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1519644>> > > > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1561450> > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1561450 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1561450>> > > > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1584499> > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1584499 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1584499>> > > > [4]: > > https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1 > <https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1> > > > <https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1 > <https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1>> > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform(a)lists.mozilla.org > <mailto:dev-platform@lists.mozilla.org> > > <mailto:dev-platform@lists.mozilla.org > <mailto:dev-platform@lists.mozilla.org>> > > > https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform> > > <https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform>> > > > > -- > > You received this message because you are subscribed to the > Google > > Groups "blink-dev" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an email to blink-dev+unsubscribe(a)chromium.org > <mailto:blink-dev%2Bunsubscribe@chromium.org> > > <mailto:blink-dev%2Bunsubscribe@chromium.org > <mailto:blink-dev%252Bunsubscribe@chromium.org>>. > > To view this discussion on the web visit > > > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-11… > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-11…> > > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-11… <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-11…>>. > > > > -- > You received this message because you are subscribed to the Google > Groups "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to blink-dev+unsubscribe(a)chromium.org > <mailto:blink-dev%2Bunsubscribe@chromium.org>. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2feb402-36ac-db… > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2feb402-36ac-db…>. >

1 0

Re: [webkit-dev] What to do about scroll anchoring?
by L. David Baron 29 Sep '19

29 Sep '19

On Sunday 2019-09-29 10:54 +1000, Cameron McCormack wrote: > How useful is scroll anchoring outside of the two cases mentioned in https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and ad iframes being inserted? Would it be feasible to make scroll anchoring a much less general mechanism, and to scope it down to handling these specific cases? I think it's also quite useful for horizontal resizes of the browser window (which can include device rotation on mobile, window resizing/maximization on desktop, and also hiding/showing of browser sidebar UI). -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)

1 0

What to do about scroll anchoring?
by Emilio Cobos Álvarez 28 Sep '19

28 Sep '19

Hi, (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or opinions, as WebKit is the only engine which does not implement scroll anchoring, though I don't know if they plan to, and Blink is the only other engine that does implement it. Please reply to dev-platform@ though.) TLDR: Scroll anchoring is really a mess. I didn't do the initial implementation of the feature in Gecko, but I've done a ton of work over the last few months to fix compat issues in our implementation (see all the bugs blocking [1]). At this point, our implementation is mostly compatible with Blink, but even with a bug-for-bug compatible implementation, we did get compat issues because of different content being served for different browsers, or because our anti-tracking protections changing the final content of the page slightly ([2] is an example of bug which only reproduces with ETP enabled only, but whose reduced test-case renders the site unusable in Chrome as well). If you hit one of the broken cases as a user you think the browser is completely broken, and the site is just unusable. I've fixed those by tweaking the heuristics Gecko uses. Those extra heuristics have also caused other compat issues, like [3], reported today, which will require other adjustments to the heuristics, etc... On top of that, the spec is not in a good state, with ton of open issues without feedback from the editors [4]. So right now I'm at a stage where I think that the feature is just not worth it. It doesn't behave predictably enough for developers, and you have no guarantee of it behaving consistently unless you test a particular browser, with a particular content in a particular viewport size... That's not great given the current dominant position of Chromium-based browsers. On top, issues with scroll anchoring are pretty hard to diagnose unless you're aware of the feature. All in all, it doesn't seem like the kind of feature that benefits a diverse web (nor web developers for that matter), and I think we should remove the feature from Gecko. Does anyone have strong opinions against removing scroll anchoring from Gecko, based on the above? Thanks, -- Emilio [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499 [4]: https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1

3 3

Re: [webkit-dev] [blink-dev] Re: What to do about scroll anchoring?
by Emilio Cobos Álvarez 27 Sep '19

27 Sep '19

Hi Steve, On 9/27/19 4:03 PM, Steve Kobes wrote: > Hi Emilio, > > My recollection is that scroll anchoring was, in fact, a mess. I do not > personally have any opinion about whether scroll anchoring should be > removed from Gecko. > > We (Chrome) decided to accept some compat issues for the sake of > launching the feature. This was a judgment call and could reasonably > have gone the other way. Right, my concern is that taking compat fallout with Chrome's market share may be acceptable, because people will likely fix their websites if they misbehave. But web developers may not take the same time to fix their site if it's broken on Firefox for Android, for example, which in turn drives Firefox users away (and you know this is a vicious cycle, the less users you have, the less people will care about fixing their websites in your browser). That being said, more generally, I care about being interoperable / predictable here for web developers, and seems like that ship may have sailed if we need to fix some Gecko-specific issues by tweaking our heuristics, but Chromium / Blink doesn't change them in the same way (which is understandable, I guess, though I've filed spec issues for our reasoning behind these changes, which I think would apply to Chrome as well). -- Emilio > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez <emilio(a)mozilla.com > <mailto:emilio@mozilla.com>> wrote: > > And, to be clear, we _can_ fix these compat issues, some way or another. > > One thought is to limit the amount of scroll adjustments without user > scrolling or stuff like that, which would prevent the "you get stuck on > the page". > > Making anchoring opt-in rather than opt-out is another option, but that > defeats most of the purpose of the feature, I guess. > > See also some of the Chromium docs on the compat issues they found[1] > and how were they trying to fix them before adding the > "layout-affecting-property changed" heuristic, which is what is on the > spec right now and what they implement. > > I just think that these are very hacky heuristics that are just > going to > bring a lot of compat pain and developer confusion. > > It doesn't help that all these things can break or not depending on the > speed at which the user scrolls, the amount of scroll events that the > user dispatches, the timing of these events relative to other > events, etc... > > -- Emilio > > [1]: > https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3N… > <https://docs.google.com/document/d/1nQAO4MYCDMn0rTkn_-WI6gjumk3Qi2Bn-MGuB3N…> > > On 9/27/19 2:23 PM, Emilio Cobos Álvarez wrote: > > Hi, > > > > (cc'ing webkit-dev@ and blink-dev@ in case they have feedback or > > opinions, as WebKit is the only engine which does not implement > scroll > > anchoring, though I don't know if they plan to, and Blink is the > only > > other engine that does implement it. Please reply to > dev-platform@ though.) > > > > TLDR: Scroll anchoring is really a mess. > > > > I didn't do the initial implementation of the feature in Gecko, > but I've > > done a ton of work over the last few months to fix compat issues > in our > > implementation (see all the bugs blocking [1]). > > > > At this point, our implementation is mostly compatible with > Blink, but > > even with a bug-for-bug compatible implementation, we did get compat > > issues because of different content being served for different > browsers, > > or because our anti-tracking protections changing the final > content of > > the page slightly ([2] is an example of bug which only reproduces > with > > ETP enabled only, but whose reduced test-case renders the site > unusable > > in Chrome as well). > > > > If you hit one of the broken cases as a user you think the > browser is > > completely broken, and the site is just unusable. > > > > I've fixed those by tweaking the heuristics Gecko uses. Those extra > > heuristics have also caused other compat issues, like [3], reported > > today, which will require other adjustments to the heuristics, etc... > > > > On top of that, the spec is not in a good state, with ton of open > issues > > without feedback from the editors [4]. > > > > So right now I'm at a stage where I think that the feature is > just not > > worth it. It doesn't behave predictably enough for developers, > and you > > have no guarantee of it behaving consistently unless you test a > > particular browser, with a particular content in a particular > viewport > > size... That's not great given the current dominant position of > > Chromium-based browsers. > > > > On top, issues with scroll anchoring are pretty hard to diagnose > unless > > you're aware of the feature. > > > > All in all, it doesn't seem like the kind of feature that benefits a > > diverse web (nor web developers for that matter), and I think we > should > > remove the feature from Gecko. > > > > Does anyone have strong opinions against removing scroll > anchoring from > > Gecko, based on the above? > > > > Thanks, > > > > -- Emilio > > > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1519644 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1519644> > > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1561450 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1561450> > > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1584499 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1584499> > > [4]: > https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1 > <https://github.com/w3c/csswg-drafts/labels/css-scroll-anchoring-1> > > _______________________________________________ > > dev-platform mailing list > > dev-platform(a)lists.mozilla.org > <mailto:dev-platform@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-platform > <https://lists.mozilla.org/listinfo/dev-platform> > > -- > You received this message because you are subscribed to the Google > Groups "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to blink-dev+unsubscribe(a)chromium.org > <mailto:blink-dev%2Bunsubscribe@chromium.org>. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-11… > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fb3b637-50f5-11…>. >

1 0

Requesting feedback about EWS comments on Bugzilla bugs
by Aakash Jain 26 Sep '19

26 Sep '19

Hi Everyone, I am gathering feedback about EWS - specially about the comments which EWS makes on the Bugzilla bugs. Currently, the comments are not very user-friendly/polished/readable and are sometimes very noisy (e.g.: 72 comments and 36 attachments by EWS in https://bugs.webkit.org/show_bug.cgi?id=177484 <https://bugs.webkit.org/show_bug.cgi?id=177484>). I am working on improving them and looking for specific ideas/feedback. Few ideas which I am considering: 1) Do not upload archive (for layout-test-results) on bugzilla, instead upload it to another server, unzip it and post a link to the results.html. Pros: a) Engineers won't have to download the attachment, unzip it, look for failures, and then delete it from their disk. They can simply click the url to view the results. b) This approach will also reduce 2 comments per failure to 1 comment. Currently there are two comments per failure, one for failure details, second for bugzilla attachment. 2) Aggregate comments from multiple queues. Pros: less noise Cons: comments would get delayed while waiting for results from other queues. (Also might be little complex to implement) 3) Improve the text of the comments to make them more readable (specific ideas are welcome). 4) When a patch becomes 'obsolete', tag the corresponding EWS comments as 'obsolete', so that they will be hidden. 5) Do not comment on bugzilla bug at all, instead send email to the author of the patch. Pros: less noisy, also this will allow to include more detailed information about the failure in email. Cons: reviewers would have to click status-bubbles to see the failures, failure information is not immediately present in the comments. What do you guys think? Thanks Aakash

8 11

Adding JSC stress test runs with other options
by Paulo Matos 20 Sep '19

20 Sep '19

Hi, Due to the failure reported in https://bugs.webkit.org/show_bug.cgi?id=202041 which I am investigating, I was attempting to add a test run of stress/regexp-unicode-surrogate-pair-increment-should-involve-length-check.js with the option --useRegExpJIT=0 Unfortunately simply adding //@ requireOptions("--useRegExpJIT=0"), makes all the tests on the file use the option instead of using the option as an addition to what was already running. Is there currently a way to say, in addition to the tests you're already running, try running with this option X? Also, is there in general any documentation on the /test language/ one can use in test headers? i.e. after //@? See http://llvm.org/docs/TestingGuide.html#constraining-test-execution for an example of such documentation. Thanks, -- Paulo Matos

2 2

Questions about JSC EWS queues
by Aakash Jain 19 Sep '19

19 Sep '19

Hi All, I am working on moving JSC EWS queues from old EWS to new EWS. I am trying to clearly understand various JSC EWS queues. I have few questions: 1) What does 'jsc-only' port represent? From https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/common/… <https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/webkitpy/common/…> it seems like Apple JSC EWS uses 'mac' port, while linux jsc EWSes use 'jsc-only' port. Is jsc-only port specific to linux? Is there a corresponding jsc port for mac? 2) Is there any difference between the three linux JSC EWSes (JSC i386, JSC MIPS32el, JSC Armv7) apart from the architecture and few queues running/skipping tests? 3) Where is the architecture for various linux JSC EWS queues configured in the old EWS code (e.g.: I don't see the architecture being added in https://trac.webkit.org/changeset/237001/webkit <https://trac.webkit.org/changeset/237001/webkit>)? Is the queue configuration for various JSC EWS queues same, and the device connected to the queue actually decides the architecture? Thanks Aakash

3 3

Drop x86 (32bit) JIT backend
by Yusuke Suzuki 16 Sep '19

16 Sep '19

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

3 5