Bug 177586

Created attachment 322061 [details] maybe it will work This is a super wimpy version of gigacage for iOS. I think it's a good place to start.

Created attachment 322084 [details] seems to work fine

Attachment 322084 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] ERROR: Source/bmalloc/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 2 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style.

Comment on attachment 322084 [details] seems to work fine r=me

Created attachment 322088 [details] the patch

Comment on attachment 322088 [details] the patch And now, with a changelog!

Comment on attachment 322088 [details] the patch r=michael on the previous version of this patch

Comment on attachment 322088 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=322088&action=review > Source/JavaScriptCore/ChangeLog:8 > + The hardest part of enabling Gigacage on iOS is that it requires loading global variables whil typo: /whil/while/

Landed in https://trac.webkit.org/changeset/222625/webkit

<rdar://problem/34721892>

Re-opened since this is blocked by bug 177664

Created attachment 322223 [details] a better approach I'm still testing it.

Attachment 322223 [details] did not pass style-queue: ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:57: g_wasEnabled is incorrectly named. Don't use underscores in your identifier names. [readability/naming/underscores] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:258: An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement. [readability/control_flow] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.h:167: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/bmalloc/bmalloc/Gigacage.h:168: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/bmalloc/bmalloc/HeapKind.cpp:26: Found header this file implements before WebCore config.h. Should be: config.h, primary header, blank line, and then alphabetically sorted. [build/include_order] [4] Total errors found: 5 in 19 files If any of these errors are false positives, please file a bug against check-webkit-style.

Created attachment 322284 [details] better patch I think this will actually work.

Attachment 322284 [details] did not pass style-queue: ERROR: Source/bmalloc/bmalloc/HeapKind.cpp:26: Found header this file implements before WebCore config.h. Should be: config.h, primary header, blank line, and then alphabetically sorted. [build/include_order] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:57: g_wasEnabled is incorrectly named. Don't use underscores in your identifier names. [readability/naming/underscores] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:258: An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement. [readability/control_flow] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.h:167: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/bmalloc/bmalloc/Gigacage.h:168: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 5 in 25 files If any of these errors are false positives, please file a bug against check-webkit-style.

Looks like GTK is red because gcc segfaulted.

Created attachment 322985 [details] the patch Rebased and tested it more

Attachment 322985 [details] did not pass style-queue: ERROR: Source/bmalloc/bmalloc/HeapKind.cpp:26: Found header this file implements before WebCore config.h. Should be: config.h, primary header, blank line, and then alphabetically sorted. [build/include_order] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:57: g_wasEnabled is incorrectly named. Don't use underscores in your identifier names. [readability/naming/underscores] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:258: An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement. [readability/control_flow] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.h:167: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/bmalloc/bmalloc/Gigacage.h:168: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 5 in 25 files If any of these errors are false positives, please file a bug against check-webkit-style.

Comment on attachment 322985 [details] the patch Attachment 322985 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/4779049 New failing tests: workers/wasm-long-compile.html

Created attachment 323002 [details] Archive of layout-test-results from ews114 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6

Comment on attachment 322985 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=322985&action=review r=me with some comments. > Source/JavaScriptCore/ChangeLog:8 > + The hardest part of enabling Gigacage on iOS is that it requires loading global variables whil "while" > Source/bmalloc/bmalloc/Gigacage.cpp:108 > +} // anonymous namespce I like that you moved the typo too. > Source/bmalloc/bmalloc/Gigacage.h:41 > +#define GIGACAGE_ALLOCATION_CAN_FAIL 1 Can this be an option instead? Seems like we want to be able to disable it. It would also be nice for the changelog to say what happens when it goes from using gigacage to it failing. What happens to allocations then, is it monotonic, etc. > Source/bmalloc/bmalloc/Gigacage.h:72 > +BINLINE bool wasEnabled() { return g_wasEnabled; } Can you just export the function, instead of exposing the bool? > Source/bmalloc/bmalloc/HeapKind.h:97 > + default: I'd just make this Primary and have no default. That way the compiler will yell if another kind is added. > Source/bmalloc/bmalloc/HeapKind.h:113 > + default: I'd just make this Primary and have no default. That way the compiler will yell if another kind is added.

(In reply to JF Bastien from comment #21) > Comment on attachment 322985 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=322985&action=review > > r=me with some comments. > > > Source/JavaScriptCore/ChangeLog:8 > > + The hardest part of enabling Gigacage on iOS is that it requires loading global variables whil > > "while" Fixed. > > > Source/bmalloc/bmalloc/Gigacage.cpp:108 > > +} // anonymous namespce > > I like that you moved the typo too. Fixed. > > > Source/bmalloc/bmalloc/Gigacage.h:41 > > +#define GIGACAGE_ALLOCATION_CAN_FAIL 1 > > Can this be an option instead? Seems like we want to be able to disable it. Can't be an "Options" option because this is bmalloc, so it sits below Options. > > It would also be nice for the changelog to say what happens when it goes > from using gigacage to it failing. What happens to allocations then, is it > monotonic, etc. I'll add blurbs. > > > Source/bmalloc/bmalloc/Gigacage.h:72 > > +BINLINE bool wasEnabled() { return g_wasEnabled; } > > Can you just export the function, instead of exposing the bool? I need things to inline it and read the bool directly for speed. > > > Source/bmalloc/bmalloc/HeapKind.h:97 > > + default: > > I'd just make this Primary and have no default. That way the compiler will > yell if another kind is added. This was deliberate! Your approach would cause the compiler to emit more branches. It would have to emit a separate branch for Primary. This could work, but I think it's sufficiently ugly that I don't want it: switch (things) { case SomeCase: case SomeOtherCase: return 1; case YetAnotherCase: } return 0; // The implicit default will fall through to here also, so there aren't any extra branches. > > > Source/bmalloc/bmalloc/HeapKind.h:113 > > + default: > > I'd just make this Primary and have no default. That way the compiler will > yell if another kind is added. Ditto.

(In reply to Build Bot from comment #20) > Created attachment 323002 [details] > Archive of layout-test-results from ews114 for mac-elcapitan > > The attached test failures were seen while running run-webkit-tests on the > mac-debug-ews. > Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6 This crash looks totally unrelated.

Created attachment 323022 [details] patch for landing

Attachment 323022 [details] did not pass style-queue: ERROR: Source/bmalloc/bmalloc/HeapKind.cpp:26: Found header this file implements before WebCore config.h. Should be: config.h, primary header, blank line, and then alphabetically sorted. [build/include_order] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:57: g_wasEnabled is incorrectly named. Don't use underscores in your identifier names. [readability/naming/underscores] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.cpp:258: An else if statement should be written as an if statement when the prior "if" concludes with a return, break, continue or goto statement. [readability/control_flow] [4] ERROR: Source/bmalloc/bmalloc/Gigacage.h:167: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/bmalloc/bmalloc/Gigacage.h:168: The parameter name "kind" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 5 in 25 files If any of these errors are false positives, please file a bug against check-webkit-style.

GTK/WPE build failures look to be in trunk.

Landed in https://trac.webkit.org/changeset/223015/webkit

FYI, it broke the AArch64 build on Linux, see https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/1878 for details. Note: I'm not interested in fixing, investigate, help fixing, etc myself. I just reported it, maybe anyone else is interested in fixing it.

(In reply to Csaba Osztrogonác from comment #28) > FYI, it broke the AArch64 build on Linux, see > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > 1878 for details. Note: I'm not interested in fixing, investigate, help > fixing, etc myself. I just reported it, maybe anyone else is interested in > fixing it. That’s unfortunate. I think we should not claim to run on arm64/Linux if nobody is around to fix things. I don’t even have such a device to test on.

(In reply to Filip Pizlo from comment #29) > (In reply to Csaba Osztrogonác from comment #28) > > FYI, it broke the AArch64 build on Linux, see > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > fixing it. > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > nobody is around to fix things. I don’t even have such a device to test on. Yeah, that's sad thing. I don't have any ARM64 machines too, (except for iPhone :P). Maybe, disabling it right now for ARM64 Linux would be the easiest option.

Committed r223025: <http://trac.webkit.org/changeset/223025>

(In reply to Yusuke Suzuki from comment #30) > (In reply to Filip Pizlo from comment #29) > > (In reply to Csaba Osztrogonác from comment #28) > > > FYI, it broke the AArch64 build on Linux, see > > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > > fixing it. > > > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > > nobody is around to fix things. I don’t even have such a device to test on. > > Yeah, that's sad thing. I don't have any ARM64 machines too, (except for > iPhone :P). > Maybe, disabling it right now for ARM64 Linux would be the easiest option. I think we should disable the JIT on that port. It would be a lot better if partly-working, partly-maintained, and party-tested ports were maintained out of tree.

(In reply to Filip Pizlo from comment #32) > (In reply to Yusuke Suzuki from comment #30) > > (In reply to Filip Pizlo from comment #29) > > > (In reply to Csaba Osztrogonác from comment #28) > > > > FYI, it broke the AArch64 build on Linux, see > > > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > > > fixing it. > > > > > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > > > nobody is around to fix things. I don’t even have such a device to test on. > > > > Yeah, that's sad thing. I don't have any ARM64 machines too, (except for > > iPhone :P). > > Maybe, disabling it right now for ARM64 Linux would be the easiest option. > > I think we should disable the JIT on that port. > > It would be a lot better if partly-working, partly-maintained, and > party-tested ports were maintained out of tree. I think ARM64 Linux JIT itself is not so bad status right now (it is tested in the bot, and the count of failures are fairly small). I don't think we do not need to disable it immediately. But if the failure count becomes super large and nobody maintains it, we should disable it.

(In reply to Yusuke Suzuki from comment #33) > > I think ARM64 Linux JIT itself is not so bad status right now (it is tested > in the bot, and the count of failures are fairly small). I don't think we do > not need to disable it immediately. > But if the failure count becomes super large and nobody maintains it, we > should disable it. I think this good status is largely due to, 1. Darwin ARM64 is basically usable for Linux ARM64. 2. We have much stable x64 Linux JSC support, which maintains C++ runtime part of JSC on Linux well.

(In reply to Yusuke Suzuki from comment #33) > (In reply to Filip Pizlo from comment #32) > > (In reply to Yusuke Suzuki from comment #30) > > > (In reply to Filip Pizlo from comment #29) > > > > (In reply to Csaba Osztrogonác from comment #28) > > > > > FYI, it broke the AArch64 build on Linux, see > > > > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > > > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > > > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > > > > fixing it. > > > > > > > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > > > > nobody is around to fix things. I don’t even have such a device to test on. > > > > > > Yeah, that's sad thing. I don't have any ARM64 machines too, (except for > > > iPhone :P). > > > Maybe, disabling it right now for ARM64 Linux would be the easiest option. > > > > I think we should disable the JIT on that port. > > > > It would be a lot better if partly-working, partly-maintained, and > > party-tested ports were maintained out of tree. > > I think ARM64 Linux JIT itself is not so bad status right now (it is tested > in the bot, and the count of failures are fairly small). I don't think we do > not need to disable it immediately. > But if the failure count becomes super large and nobody maintains it, we > should disable it. Imagine if someone needed to ship trunk WebKit on arm64/Linux. Would we want them to use cloop or the JIT? I would argue that it would be better if they shipped cloop, if they were using the current trunk. I think this would be better because anyone shipping a product would rather ship something that actually works than something that performs well on benchmarks. Based on this, I think we should disable the JIT on arm64/Linux. It’s not enough to just have some bots that build it or even periodically runs out tests. For a JIT port to be shippable it needs some active attention.

(In reply to Yusuke Suzuki from comment #34) > (In reply to Yusuke Suzuki from comment #33) > > > > I think ARM64 Linux JIT itself is not so bad status right now (it is tested > > in the bot, and the count of failures are fairly small). I don't think we do > > not need to disable it immediately. > > But if the failure count becomes super large and nobody maintains it, we > > should disable it. > > I think this good status is largely due to, > > 1. Darwin ARM64 is basically usable for Linux ARM64. > 2. We have much stable x64 Linux JSC support, which maintains C++ runtime > part of JSC on Linux well. Right, but there are differences that have to be maintained, like errata and ABI subtleties.

(In reply to Filip Pizlo from comment #36) > (In reply to Yusuke Suzuki from comment #34) > > (In reply to Yusuke Suzuki from comment #33) > > > > > > I think ARM64 Linux JIT itself is not so bad status right now (it is tested > > > in the bot, and the count of failures are fairly small). I don't think we do > > > not need to disable it immediately. > > > But if the failure count becomes super large and nobody maintains it, we > > > should disable it. > > > > I think this good status is largely due to, > > > > 1. Darwin ARM64 is basically usable for Linux ARM64. > > 2. We have much stable x64 Linux JSC support, which maintains C++ runtime > > part of JSC on Linux well. > > Right, but there are differences that have to be maintained, like errata and > ABI subtleties. Right. I think we need some discussions on mailing list before disabling ARM64 Linux JIT. But if nobody is interested in maintaining this, I support disabling it. I don't think removing code would be required because I don't think any ARM64/Linux JIT specific code exists in JSC right now. And I do not think we should not have a ARM64/Linux bot with JIT. But the default option should be disabling JIT if there is no maintainer.

(In reply to Yusuke Suzuki from comment #37) > (In reply to Filip Pizlo from comment #36) > > (In reply to Yusuke Suzuki from comment #34) > > > (In reply to Yusuke Suzuki from comment #33) > > > > > > > > I think ARM64 Linux JIT itself is not so bad status right now (it is tested > > > > in the bot, and the count of failures are fairly small). I don't think we do > > > > not need to disable it immediately. > > > > But if the failure count becomes super large and nobody maintains it, we > > > > should disable it. > > > > > > I think this good status is largely due to, > > > > > > 1. Darwin ARM64 is basically usable for Linux ARM64. > > > 2. We have much stable x64 Linux JSC support, which maintains C++ runtime > > > part of JSC on Linux well. > > > > Right, but there are differences that have to be maintained, like errata and > > ABI subtleties. > > Right. I think we need some discussions on mailing list before disabling > ARM64 Linux JIT. > But if nobody is interested in maintaining this, I support disabling it. > > I don't think removing code would be required because I don't think any > ARM64/Linux JIT specific code exists in JSC right now. There totally is some. :-) It’s not a lot, but I propose to remove it if it is dead to testing. We have no way of knowing if it has survived refactorings. > And I do not think we should not have a ARM64/Linux bot with JIT. > But the default option should be disabling JIT if there is no maintainer. Yeah.

(In reply to Filip Pizlo from comment #29) > (In reply to Csaba Osztrogonác from comment #28) > > FYI, it broke the AArch64 build on Linux, see > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > fixing it. > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > nobody is around to fix things. I don’t even have such a device to test on. Linux port maintainers are committed to maintaining JIT levels on ARM64. We've actually (while enabling FTL) in the past committed fixes that might as well have positively affected the iOS platform, barring some peculiarities in the Apple ARM64 CPU implementations. Ossy doesn't represent us in that regard, even if he's actually in control of the tester builders and cares enough to report any failures as they occur, and especially when he immediately relieves himself from any work to fix things.

(In reply to Zan Dobersek from comment #39) > (In reply to Filip Pizlo from comment #29) > > (In reply to Csaba Osztrogonác from comment #28) > > > FYI, it broke the AArch64 build on Linux, see > > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > > fixing it. > > > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > > nobody is around to fix things. I don’t even have such a device to test on. > > Linux port maintainers are committed to maintaining JIT levels on ARM64. > We've actually (while enabling FTL) in the past committed fixes that might > as well have positively affected the iOS platform, barring some > peculiarities in the Apple ARM64 CPU implementations. > > Ossy doesn't represent us in that regard, even if he's actually in control > of the tester builders and cares enough to report any failures as they > occur, and especially when he immediately relieves himself from any work to > fix things. Is there a bot running Linux/arm64 tests and benchmarks? Without those things, you might as well use the cloop. The fixes I remember were specific to non-Apple CPUs.

Re-opened since this is blocked by bug 178093

We rolled this out because it most likely regressed Kraken on iOS by 20%. It may have also regressed ARES-6, JetStream and JSBench.

Reopening because bugzilla conflict resolution sucks.

Relanded in https://trac.webkit.org/changeset/223113/webkit

(In reply to Filip Pizlo from comment #40) > Is there a bot running Linux/arm64 tests and benchmarks? Without those > things, you might as well use the cloop. > Yes, there are Linux JSC ARMv7 and ARM64 bots here: https://build.webkit.org/waterfall?category=misc (currently maintained by Ossy). I will look into adding more Linux JSC bots for ARM64 and ARMv7-Thumb2 (as well as EWS bots) maintained by Igalia ASAP.

(In reply to Filip Pizlo from comment #40) > (In reply to Zan Dobersek from comment #39) > > (In reply to Filip Pizlo from comment #29) > > > (In reply to Csaba Osztrogonác from comment #28) > > > > FYI, it broke the AArch64 build on Linux, see > > > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > > > fixing it. > > > > > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > > > nobody is around to fix things. I don’t even have such a device to test on. > > > > Linux port maintainers are committed to maintaining JIT levels on ARM64. > > We've actually (while enabling FTL) in the past committed fixes that might > > as well have positively affected the iOS platform, barring some > > peculiarities in the Apple ARM64 CPU implementations. > > > > Ossy doesn't represent us in that regard, even if he's actually in control > > of the tester builders and cares enough to report any failures as they > > occur, and especially when he immediately relieves himself from any work to > > fix things. > > Is there a bot running Linux/arm64 tests and benchmarks? Without those > things, you might as well use the cloop. > There's existing ones, but we'll be adding our own. > > The fixes I remember were specific to non-Apple CPUs. r215731 isn't. It fixed test failures on Linux. I wouldn't know about iOS because there's no public testers. https://trac.webkit.org/changeset/215731/webkit

(In reply to Zan Dobersek from comment #46) > (In reply to Filip Pizlo from comment #40) > > (In reply to Zan Dobersek from comment #39) > > > (In reply to Filip Pizlo from comment #29) > > > > (In reply to Csaba Osztrogonác from comment #28) > > > > > FYI, it broke the AArch64 build on Linux, see > > > > > https://build.webkit.org/builders/JSCOnly%20Linux%20AArch64%20Release/builds/ > > > > > 1878 for details. Note: I'm not interested in fixing, investigate, help > > > > > fixing, etc myself. I just reported it, maybe anyone else is interested in > > > > > fixing it. > > > > > > > > That’s unfortunate. I think we should not claim to run on arm64/Linux if > > > > nobody is around to fix things. I don’t even have such a device to test on. > > > > > > Linux port maintainers are committed to maintaining JIT levels on ARM64. > > > We've actually (while enabling FTL) in the past committed fixes that might > > > as well have positively affected the iOS platform, barring some > > > peculiarities in the Apple ARM64 CPU implementations. > > > > > > Ossy doesn't represent us in that regard, even if he's actually in control > > > of the tester builders and cares enough to report any failures as they > > > occur, and especially when he immediately relieves himself from any work to > > > fix things. > > > > Is there a bot running Linux/arm64 tests and benchmarks? Without those > > things, you might as well use the cloop. > > > > There's existing ones, but we'll be adding our own. > > > > > The fixes I remember were specific to non-Apple CPUs. > > r215731 isn't. It fixed test failures on Linux. I wouldn't know about iOS > because there's no public testers. > https://trac.webkit.org/changeset/215731/webkit That looks like it might be due to cpu differences.

(In reply to Carlos Alberto Lopez Perez from comment #45) > (In reply to Filip Pizlo from comment #40) > > Is there a bot running Linux/arm64 tests and benchmarks? Without those > > things, you might as well use the cloop. > > > > Yes, there are Linux JSC ARMv7 and ARM64 bots here: > https://build.webkit.org/waterfall?category=misc (currently maintained by > Ossy). > > I will look into adding more Linux JSC bots for ARM64 and ARMv7-Thumb2 (as > well as EWS bots) maintained by Igalia ASAP. The 32-bit JITs are not maintained anymore. We are probably going to remove that code soon.

(In reply to Filip Pizlo from comment #48) > (In reply to Carlos Alberto Lopez Perez from comment #45) > > (In reply to Filip Pizlo from comment #40) > > > Is there a bot running Linux/arm64 tests and benchmarks? Without those > > > things, you might as well use the cloop. > > > > > > > Yes, there are Linux JSC ARMv7 and ARM64 bots here: > > https://build.webkit.org/waterfall?category=misc (currently maintained by > > Ossy). > > > > I will look into adding more Linux JSC bots for ARM64 and ARMv7-Thumb2 (as > > well as EWS bots) maintained by Igalia ASAP. > > The 32-bit JITs are not maintained anymore. We are probably going to remove > that code soon. The JIT on ARMv7 Thumb2 is currently extensively used in production by a lot of people (including us). It receives a fair amount of testing.

(In reply to Carlos Alberto Lopez Perez from comment #49) > (In reply to Filip Pizlo from comment #48) > > (In reply to Carlos Alberto Lopez Perez from comment #45) > > > (In reply to Filip Pizlo from comment #40) > > > > Is there a bot running Linux/arm64 tests and benchmarks? Without those > > > > things, you might as well use the cloop. > > > > > > > > > > Yes, there are Linux JSC ARMv7 and ARM64 bots here: > > > https://build.webkit.org/waterfall?category=misc (currently maintained by > > > Ossy). > > > > > > I will look into adding more Linux JSC bots for ARM64 and ARMv7-Thumb2 (as > > > well as EWS bots) maintained by Igalia ASAP. > > > > The 32-bit JITs are not maintained anymore. We are probably going to remove > > that code soon. > > The JIT on ARMv7 Thumb2 is currently extensively used in production by a lot > of people (including us). It receives a fair amount of testing. When we add new features to JSC, we don’t want to also add them to 32-bit. There are now many features that have never been ported to 32-bit. This is because there is basically zero manpower going into 32-but maintenance. You can continue to use that code from a branch or fork if it’s removed from trunk.

(In reply to Filip Pizlo from comment #50) > (In reply to Carlos Alberto Lopez Perez from comment #49) > > (In reply to Filip Pizlo from comment #48) > > > (In reply to Carlos Alberto Lopez Perez from comment #45) > > > > (In reply to Filip Pizlo from comment #40) > > > > > Is there a bot running Linux/arm64 tests and benchmarks? Without those > > > > > things, you might as well use the cloop. > > > > > > > > > > > > > Yes, there are Linux JSC ARMv7 and ARM64 bots here: > > > > https://build.webkit.org/waterfall?category=misc (currently maintained by > > > > Ossy). > > > > > > > > I will look into adding more Linux JSC bots for ARM64 and ARMv7-Thumb2 (as > > > > well as EWS bots) maintained by Igalia ASAP. > > > > > > The 32-bit JITs are not maintained anymore. We are probably going to remove > > > that code soon. > > > > The JIT on ARMv7 Thumb2 is currently extensively used in production by a lot > > of people (including us). It receives a fair amount of testing. > > When we add new features to JSC, we don’t want to also add them to 32-bit. > There are now many features that have never been ported to 32-bit. This is > because there is basically zero manpower going into 32-but maintenance. > > You can continue to use that code from a branch or fork if it’s removed from > trunk. We can discuss this on Friday at the contributors meeting. It's well off the topic of this bug.

Comment on attachment 323022 [details] patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=323022&action=review > Source/JavaScriptCore/offlineasm/arm64.rb:941 > + when "globaladdr" > + uid = $asm.newUID > + $asm.puts "L_offlineasm_loh_adrp_#{uid}:" > + $asm.puts "adrp #{operands[1].arm64Operand(:ptr)}, #{operands[0].asmLabel}@GOTPAGE" > + $asm.puts "L_offlineasm_loh_ldr_#{uid}:" > + $asm.puts "ldr #{operands[1].arm64Operand(:ptr)}, [#{operands[1].arm64Operand(:ptr)}, #{operands[0].asmLabel}@GOTPAGEOFF]" > + $asm.deferAction { > + $asm.puts ".loh AdrpLdrGot L_offlineasm_loh_adrp_#{uid}, L_offlineasm_loh_ldr_#{uid}" > + } Two issues here that broke the ARM64 build on Linux: - GOTPAGE and GOTPAGEOFF relocations don't work with ELF, - GCC doesn't support the link-time optimization hints that are triggered through the .loh directive. Opened bug #178130 to address that.

(In reply to Zan Dobersek from comment #51) > We can discuss this on Friday at the contributors meeting. It's well off > the topic of this bug. Yes, I'm looking forward to talking about this at the Contributors Meeting. Igalia really wants to keep this code in upstream WebKit. We also understand that won't happen unless we significantly ramp up our upstream JSC maintenance efforts.

Re-opened since this is blocked by bug 178182

*** Bug 178050 has been marked as a duplicate of this bug. ***

Relanded in https://trac.webkit.org/changeset/223239/webkit