Re: --ion-parallel-compile=on is now the default in the shell

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: --ion-parallel-compile=on is now the default in the shell

sunfish
On Thursday, December 5, 2013 10:35:09 AM UTC-8, Terrence Cole wrote:
> If you know of any other ways that the browser build is substantially
>
> different from the shell build, please let me know.

In the browser, the JS engine is dynamically linked in as part of libxul, so it is not in the main executable, while in the shell, it appears to be statically linked into the main executable. This causes a variety of minor differences in how symbols in the JS engine are referenced, including by the code emitted by the JIT.

Would it be worthwhile to link the js shell with the libmozjs dynamic library, to minimize such differences?

Dan
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: --ion-parallel-compile=on is now the default in the shell

Terrence Cole-3
On 12/19/2013 10:58 AM, [hidden email] wrote:
> On Thursday, December 5, 2013 10:35:09 AM UTC-8, Terrence Cole wrote:
>> If you know of any other ways that the browser build is substantially
>>
>> different from the shell build, please let me know.
>
> In the browser, the JS engine is dynamically linked in as part of libxul, so it is not in the main executable, while in the shell, it appears to be statically linked into the main executable. This causes a variety of minor differences in how symbols in the JS engine are referenced, including by the code emitted by the JIT.

Good thought!

> Would it be worthwhile to link the js shell with the libmozjs dynamic library, to minimize such differences?

I'm not sure. I was under the impression that we linked differently on
windows from other platforms. I think where and how we get linked is
also currently in flux because of ICU.

> Dan
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: --ion-parallel-compile=on is now the default in the shell

Terrence Cole-3
In reply to this post by sunfish
On 12/19/2013 10:58 AM, [hidden email] wrote:
> On Thursday, December 5, 2013 10:35:09 AM UTC-8, Terrence Cole wrote:
>> If you know of any other ways that the browser build is substantially
>>
>> different from the shell build, please let me know.
>
> In the browser, the JS engine is dynamically linked in as part of libxul, so it is not in the main executable, while in the shell, it appears to be statically linked into the main executable. This causes a variety of minor differences in how symbols in the JS engine are referenced, including by the code emitted by the JIT.

Good thought!

> Would it be worthwhile to link the js shell with the libmozjs dynamic library, to minimize such differences?

I'm not sure. I was under the impression that we linked differently on
windows from other platforms. I think where and how we get linked is
also currently in flux because of ICU.

> Dan
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: --ion-parallel-compile=on is now the default in the shell

Ehsan Akhgari
In reply to this post by Terrence Cole-3
On 12/19/2013, 4:08 PM, Terrence Cole wrote:

> On 12/19/2013 10:58 AM, [hidden email] wrote:
>> On Thursday, December 5, 2013 10:35:09 AM UTC-8, Terrence Cole wrote:
>>> If you know of any other ways that the browser build is substantially
>>>
>>> different from the shell build, please let me know.
>>
>> In the browser, the JS engine is dynamically linked in as part of libxul, so it is not in the main executable, while in the shell, it appears to be statically linked into the main executable. This causes a variety of minor differences in how symbols in the JS engine are referenced, including by the code emitted by the JIT.
>
> Good thought!
>
>> Would it be worthwhile to link the js shell with the libmozjs dynamic library, to minimize such differences?
>
> I'm not sure. I was under the impression that we linked differently on
> windows from other platforms. I think where and how we get linked is
> also currently in flux because of ICU.

There is a configure option called --enable-shared-js which determines
whether the JS engine is linked into libxul or not.  That flag is on by
default on Windows, which means that mozjs.dll and xul.dll are separate
there, but it's off everywhere else which means that the js engine is
linked inside libxul everywhere else by default.  There are people who
build with --enable-shared-js on Linux and Mac though so we want to keep
both working.

About ICU, in order to make it possible to use ICU from both js and
gecko, we link it statically if js is not shared, and dynamically otherwise.

Cheers,
Ehsan

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: --ion-parallel-compile=on is now the default in the shell

sunfish
In reply to this post by Terrence Cole-3
On Thursday, December 19, 2013 1:51:22 PM UTC-8, Ehsan Akhgari wrote:

> There is a configure option called --enable-shared-js which determines
>
> whether the JS engine is linked into libxul or not.  That flag is on by
>
> default on Windows, which means that mozjs.dll and xul.dll are separate
>
> there, but it's off everywhere else which means that the js engine is
>
> linked inside libxul everywhere else by default.  There are people who
>
> build with --enable-shared-js on Linux and Mac though so we want to keep
>
> both working.

For this thread, which dll it's in is less important than whether it's in a dll at all. Currently the js engine is statically linked into the standalone js executable. It isn't a big difference, but it's a difference.

This appears to be the relevant line, if I'm reading this correctly:

http://mxr.mozilla.org/mozilla-central/source/js/src/shell/Makefile.in#7

Dan
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine