Re: Rust and --enable-shared-js
On Tue, Oct 02, 2018 at 03:25:04PM +0300, Henri Sivonen wrote: > On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky wrote: > > On 9/24/18 4:04 AM, Henri Sivonen wrote: > >> > >> How important is --enable-shared-js? I gather its use case is making > >> builds faster for SpiderMonkey developers. > > > > > > My use case for it is to be able to use the "exclude samples from library X" > > or "collapse library X" tools in profilers (like Instruments) to more easily > > break down profiles into "page JS" and "Gecko things". I would probably be worthwhile to be able to do that without --enable-shared-js, only because that's not how Nightlies are shipped, and this seems like something that can be useful to do on nightlies. Is grouping by js::* JS* a workable alternative? > On Mon, Sep 24, 2018 at 1:24 PM, Mike Hommey wrote: > >> How important is --enable-shared-js? I gather its use case is making > >> builds faster for SpiderMonkey developers. Is that the only use case? > > > > for _Gecko_ developers. > > This surprises me. Doesn't the build system take care of not > rebuilding SpiderMonkey if it hasn't been edited? Is this only about > the link time? Yes, it reduces link time for libxul because libmozjs doesn't need to be linked statically to it. That might not matter anymore, but it's better to know if people rely on that. I'd like to note that making libxul always have libmozjs statically linked could allow to move some things from libmozglue to libxul. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and --enable-shared-js
(Sorry, I polled #jsapi about this issue back when you first posted and then forgot to reply with the response.) It doesn't seem like any SM devs use --enable-shared-js for their own development but we do know that various embedders (e.g. GNOME) use the JS shared library and so we'd like to keep that configuration tested and working. One hybrid option is thus: - drop support for building Gecko with --enable-shared-js (avoiding the symbol conflict issue), but keep --enable-shared-js as a configure option for JS shell builds - have at least one tier-1 --enable-shared-js JS shell build on automation so that we at least keep it working Cheers, Luke On Tue, Oct 2, 2018 at 7:25 AM Henri Sivonen wrote: > On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky wrote: > > On 9/24/18 4:04 AM, Henri Sivonen wrote: > >> > >> How important is --enable-shared-js? I gather its use case is making > >> builds faster for SpiderMonkey developers. > > > > > > My use case for it is to be able to use the "exclude samples from > library X" > > or "collapse library X" tools in profilers (like Instruments) to more > easily > > break down profiles into "page JS" and "Gecko things". > > OK. > > On Mon, Sep 24, 2018 at 1:24 PM, Mike Hommey wrote: > >> How important is --enable-shared-js? I gather its use case is making > >> builds faster for SpiderMonkey developers. Is that the only use case? > > > > for _Gecko_ developers. > > This surprises me. Doesn't the build system take care of not > rebuilding SpiderMonkey if it hasn't been edited? Is this only about > the link time? > > What's the conclusion regarding next steps? Should I introduce > js_-prefixed copies of the four Rust FFI functions that I want to make > available to SpiderMonkey? > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and --enable-shared-js
On Mon, Sep 24, 2018 at 3:24 PM, Boris Zbarsky wrote: > On 9/24/18 4:04 AM, Henri Sivonen wrote: >> >> How important is --enable-shared-js? I gather its use case is making >> builds faster for SpiderMonkey developers. > > > My use case for it is to be able to use the "exclude samples from library X" > or "collapse library X" tools in profilers (like Instruments) to more easily > break down profiles into "page JS" and "Gecko things". OK. On Mon, Sep 24, 2018 at 1:24 PM, Mike Hommey wrote: >> How important is --enable-shared-js? I gather its use case is making >> builds faster for SpiderMonkey developers. Is that the only use case? > > for _Gecko_ developers. This surprises me. Doesn't the build system take care of not rebuilding SpiderMonkey if it hasn't been edited? Is this only about the link time? What's the conclusion regarding next steps? Should I introduce js_-prefixed copies of the four Rust FFI functions that I want to make available to SpiderMonkey? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and --enable-shared-js
On 9/24/18 4:04 AM, Henri Sivonen wrote: How important is --enable-shared-js? I gather its use case is making builds faster for SpiderMonkey developers. My use case for it is to be able to use the "exclude samples from library X" or "collapse library X" tools in profilers (like Instruments) to more easily break down profiles into "page JS" and "Gecko things". That said, I haven't done that very much recently... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and --enable-shared-js
On Mon, Sep 24, 2018 at 11:04:43AM +0300, Henri Sivonen wrote: > There's an effort to add Rust code to SpiderMonkey: > https://bugzilla.mozilla.org/show_bug.cgi?id=1490948 > > This will introduce a jsrust_shared crate that will just depend on all > the Rust crates that SpiderMonkey needs like gkrust_shared depends on > the crates the rest of Gecko needs. > > This is fine both for building standalone SpiderMonkey (a top-level > jsrust will produce a .a and depend on jsrust_shared) and SpiderMonkey > as part of libxul (gkrust_shared will depend on jsrust_shared). > > However, there exists a third configuration: --enable-shared-js. With > this option, SpiderMonkey is linked dynamically instead of being baked > into libxul. This is fine as long the set of FFI-exposing crates that > SpiderMonkey depends on and the set of FFI-exposing crates that the > rest of Gecko depends on are disjoint. If they aren't disjoint, a > symbol conflict is expected. > > AFAICT, this could be solved in at least three ways: > > 1) Keeping the sets disjoint. If both SpiderMonkey and the rest of > Gecko want to call the same Rust code, introduce a differently-named > FFI binding for SpiderMonkey. > > 2) Making FFI symbols .so-internal so that they don't conflict > between shared libraries. Per > https://bugzilla.mozilla.org/show_bug.cgi?id=1490603 , it seems that > this would require rustc changes that don't exist yet. > > 3) Dropping support for --enable-shared-js > > For my immediate use case, I want to make 4 functions available both > to SpiderMonkey and the rest of Gecko, so option #1 is feasible, but > it won't scale. Maybe #2 becomes feasible before scaling up #1 becomes > a problem. > > But still, I'm curious: > > How important is --enable-shared-js? I gather its use case is making > builds faster for SpiderMonkey developers. Is that the only use case? for _Gecko_ developers. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
