(function() { ... })() IIFE pattern should get its body const-folded. This won't make much
runtime difference on JIT, but can be significant in interpreted code (and saves time for
JIT codegen).
Based-on: m-c 632020
Fix regression from difference between Interpreter (old) and ElemOpEmitter (new). We don't have
any Ion/IC support for these ops.
Based-on: m-c 1472211
Critical note: this potentially reduces the strength of TLS 1.3 and
should only be enabled if absolutely necessary to access a site.
A browser restart is required for the pref change to take effect as it
is set on NSS initialization.
Resolves#1831
Shared JS is confirmed working fine in Windows after a week of testing.
Non-Windows will have to wait unfortunately. The JS_SHARED_LIBRARY option is
kept for easy testing on those unsupported platforms.
The trace in Spidermonkey's old-configure is causing the MOZ_CONFIG_ICU function
to be called twice, which is not desirable as it can cause the MOZ_SHARED_ICU
check in build/autoconf/icu.m4 to fail and build an ICU data file even if we're
building ICU as a shared library.
It seems that if we're going to enable JS_SHARED_LIBRARY, we need ICU to be a
shared library too in order to prevent code duplication in mozjs.dll bloating
it to a whopping 21 MB.
This unfortunately means we have to fold icudata back to icu itself. But since
icudata is still separated from libxul (which is what really matters for #1451),
I think this is a fair compromise.
Building ICU as shared is offered as an option via --enable-shared-icu. But
technically you really need --enable-shared-icu if you're going to use
--enable-shared-js. Unfortunately I can't make configure exit with an error if
MOZ_SHARED_ICU is not defined when JS_SHARED_LIBRARY is enabled, because options
are controlled by different configure scripts (icu is based on bash, while js is
based on python), and I have no idea how to pass MOZ_SHARED_ICU to js's
moz.configure.
Tag #62
This is the one I don't understand how it fixed the bustage. Why is it needed
to remove JS_PUBLIC_API..? It would seem counter-intuitive, but it wasn't...
The unsafeSet method is based on Jon Coppeard's part 2 patch for Mozilla bug
1306008. This is needed because of the use of unsafeSet in rekey() of
MovableCellHasher<JS::Heap<T>>
Skia does some nasty things that break with DLL calls like having virtual dtors
without a body definition (and it's honestly surprising that it even builds to
begin with the way it's done, but apparently they use some linking symbol voodoo
to work around that in dependent classes).
Not wanting to have to pull Google code apart to try and fix that for something
we're only using for canvas anyway, it's better to just let Skia reside in
libxul instead.
