JavaScriptCore on Fuchsia
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 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.
Hi Adam, This looks super interesting! I have some questions: - Does your JSC port enable all of JSC’s optimization features, like the FTL JIT and concurrent GC? - Is it a goal to enable basically everything we enable, long term? - Is this 32-bit, 64-bit, or both? - Is this mainly for ARM, x86, some other CPU, or lots of CPUs? - Do you plan to do significant work on JSC, or do you mainly want to just stay up to date with what we’re doing? More thoughts inline:
On Jun 26, 2018, at 2:00 PM, Adam Barth <abarth@webkit.org> 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.
I’d be OK with this.
2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports Fuchsia.
In my opinion, SVN branches are not significantly better than (1), and in many ways they are worse. I wouldn’t advocate for this.
3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org.
I think that I’d be OK with this, too. This seems better than (1) if you want to stay up-to-date. -Filip
For reference, here's the patch we applied to WTF and JavaScriptCore to enable Fuchsia support:
https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96
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
On Tue, Jun 26, 2018 at 2:08 PM Filip Pizlo <fpizlo@apple.com> wrote:
This looks super interesting!
Thanks. :)
I have some questions:
- Does your JSC port enable all of JSC’s optimization features, like the FTL JIT and concurrent GC?
Nope. I believe we just have the interpreter working.
- Is it a goal to enable basically everything we enable, long term?
The Fuchsia project itself doesn't have any particular goals for JavaScriptCore. It's possible that our customers who want to use JavaScriptCore on Fuchsia will have goals for additional functionality in the future, but assuming we host the code on svn.webkit.org, I would imagine recommending that those customers interact directly with the WebKit project.
- Is this 32-bit, 64-bit, or both?
Fuchsia supports only 64-bit architectures. We have no interest in 32-bit support in JavaScriptCore.
- Is this mainly for ARM, x86, some other CPU, or lots of CPUs?
Fuchsia supports x86_64 and aarch64.
- Do you plan to do significant work on JSC, or do you mainly want to just stay up to date with what we’re doing?
I'd like to foster a healthy dynamic between the WebKit project and our mutual customers. It's hard for me to predict to where those customers will fall on that spectrum, but I would not anticipate the Fuchsia project itself making significant contributions to JSC. However, I would anticipate us maintaining the integration between JavaScriptCore and Fuchsia.
More thoughts inline:
On Jun 26, 2018, at 2:00 PM, Adam Barth <abarth@webkit.org> 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.
I’d be OK with this.
2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports Fuchsia.
In my opinion, SVN branches are not significantly better than (1), and in many ways they are worse. I wouldn’t advocate for this.
Make sense.
3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org.
I think that I’d be OK with this, too. This seems better than (1) if you want to stay up-to-date.
Thanks! Adam
For reference, here's the patch we applied to WTF and JavaScriptCore to enable Fuchsia support:
https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96
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
On Jun 26, 2018, at 2:28 PM, Adam Barth <abarth@webkit.org> wrote:
On Tue, Jun 26, 2018 at 2:08 PM Filip Pizlo <fpizlo@apple.com> wrote:
This looks super interesting!
Thanks. :)
I have some questions:
- Does your JSC port enable all of JSC’s optimization features, like the FTL JIT and concurrent GC?
Nope. I believe we just have the interpreter working.
- Is it a goal to enable basically everything we enable, long term?
The Fuchsia project itself doesn't have any particular goals for JavaScriptCore. It's possible that our customers who want to use JavaScriptCore on Fuchsia will have goals for additional functionality in the future, but assuming we host the code on svn.webkit.org, I would imagine recommending that those customers interact directly with the WebKit project.
Gotcha.
- Is this 32-bit, 64-bit, or both?
Fuchsia supports only 64-bit architectures. We have no interest in 32-bit support in JavaScriptCore.
Music to my ears.
- Is this mainly for ARM, x86, some other CPU, or lots of CPUs?
Fuchsia supports x86_64 and aarch64.
Lovely.
- Do you plan to do significant work on JSC, or do you mainly want to just stay up to date with what we’re doing?
I'd like to foster a healthy dynamic between the WebKit project and our mutual customers. It's hard for me to predict to where those customers will fall on that spectrum, but I would not anticipate the Fuchsia project itself making significant contributions to JSC. However, I would anticipate us maintaining the integration between JavaScriptCore and Fuchsia.
More thoughts inline:
On Jun 26, 2018, at 2:00 PM, Adam Barth <abarth@webkit.org> 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.
I’d be OK with this.
2. Maintain a branch of JavaScriptCore in svn.webkit.org that supports Fuchsia.
In my opinion, SVN branches are not significantly better than (1), and in many ways they are worse. I wouldn’t advocate for this.
Make sense.
3. Maintain support for JavaScriptCore in the mainline of svn.webkit.org.
I think that I’d be OK with this, too. This seems better than (1) if you want to stay up-to-date.
Thanks!
Based on this, I think that it’s ideal for it to be in svn.webkit.org <http://svn.webkit.org/>. -Filip
Adam
For reference, here's the patch we applied to WTF and JavaScriptCore to enable Fuchsia support:
https://gist.github.com/abarth/b4fc909d83be5133cd7a5af209757e96
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
Sounds very cool! On Wed, Jun 27, 2018 at 6:01 AM Adam Barth <abarth@webkit.org> 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
On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI <utatane.tea@gmail.com> wrote:
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.
I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would suffice? Then instead of a separate Fushcia port, we would just have the existing JSCOnly port running on Fuschia.
Hi Yusuke, For some reason, your original email missed my inbox. On Wed, Jun 27, 2018 at 7:53 PM Michael Catanzaro <mcatanzaro@igalia.com> wrote:
On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI <utatane.tea@gmail.com> wrote:
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.).
So far, I seem to be able to control those features on a build level through CMake.
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.
Fuchsia appears to need to be a port in the sense of having an OptionsFuchsia.cmake in order to set the target triple to x86_64-unknown-fuchsia. I didn't find any other uses of CMAKE_CXX_COMPILER_TARGET in WebKit. Is there some other mechanism folks use to set the target triple (or maybe other folks aren't crosscompiling using clang)?
I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would suffice? Then instead of a separate Fushcia port, we would just have the existing JSCOnly port running on Fuschia.
That sounds like a good approach to start with. If we run into trouble, we might need to adjust. Adam
On Wed, Jun 27, 2018 at 8:05 PM Adam Barth <abarth@webkit.org> wrote:
Hi Yusuke,
For some reason, your original email missed my inbox.
On Wed, Jun 27, 2018 at 7:53 PM Michael Catanzaro <mcatanzaro@igalia.com> wrote:
On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI <utatane.tea@gmail.com> wrote:
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.).
So far, I seem to be able to control those features on a build level through CMake.
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.
Fuchsia appears to need to be a port in the sense of having an OptionsFuchsia.cmake in order to set the target triple to x86_64-unknown-fuchsia. I didn't find any other uses of CMAKE_CXX_COMPILER_TARGET in WebKit. Is there some other mechanism folks use to set the target triple (or maybe other folks aren't crosscompiling using clang)?
I discovered CMAKE_TOOLCHAIN_FILE and figured out how to make this work: https://bugs.webkit.org/show_bug.cgi?id=187133
I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would suffice? Then instead of a separate Fushcia port, we would just have the existing JSCOnly port running on Fuschia.
That sounds like a good approach to start with. If we run into trouble, we might need to adjust.
Adam
Hello, (Just a quick note, below.) On Wed, 27 Jun 2018 21:35:40 -0700, Adam Barth <abarth@webkit.org> wrote:
On Wed, Jun 27, 2018 at 8:05 PM Adam Barth <abarth@webkit.org> wrote:
Hi Yusuke,
For some reason, your original email missed my inbox.
On Wed, Jun 27, 2018 at 7:53 PM Michael Catanzaro <mcatanzaro@igalia.com> wrote:
On Tue, Jun 26, 2018 at 6:49 PM, Yusuke SUZUKI <utatane.tea@gmail.com> wrote:
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.).
So far, I seem to be able to control those features on a build level through CMake.
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.
Fuchsia appears to need to be a port in the sense of having an OptionsFuchsia.cmake in order to set the target triple to x86_64-unknown-fuchsia. I didn't find any other uses of CMAKE_CXX_COMPILER_TARGET in WebKit. Is there some other mechanism folks use to set the target triple (or maybe other folks aren't crosscompiling using clang)?
I discovered CMAKE_TOOLCHAIN_FILE and figured out how to make this work:
Using CMAKE_TOOLCHAIN_FILE definitely should work, and if it ever breaks we will want to fix things. This is what many cross-compilation systems (example: Buildroot) are using for building the GTK+ and WPE ports, which means we'll notice if any issue is introduced [1].
I wonder if PLATFORM(FUSHCIA) is even needed? Maybe OS(FUSHCIA) would suffice? Then instead of a separate Fushcia port, we would just have the existing JSCOnly port running on Fuschia.
That sounds like a good approach to start with. If we run into trouble, we might need to adjust.
As long as having only OS(FUCHSIA) satisfies your needs, I also think it is simpler to avoid PLATFORM(FUCHSIA) and reusing the JSCOnly port for now. Cheers, Adrián --- [1] I'm subscribed to Buildroot's autobuilder (http://autobuild.buildroot.net) for the “webkitgtk” package, which has been handy to fix quite some build issues in the past :-)
participants (5)
-
Adam Barth
-
Adrian Perez de Castro
-
Filip Pizlo
-
Michael Catanzaro
-
Yusuke SUZUKI