(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
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>>
(x) = function() {..} is an extremely sparsely documented way to prevent function name inference.
Modeled after how BytecodeEmitter::emitInitializer does it.
Attn: this plain patch port still contains issues caused by differences in the
ParseNode tree that will be fixed in the following commits.
Based-on: m-c 1466000/{7-10}
This removed a bit of reduncancy and makes stack building easier to follow.
- Move call context handling from BytecodeEmitter::emitGetNameAtLocation to BytecodeEmitter::emitCalleeAndThis
- Add stack comments for prop and elem related methods in BytecodeEmitter
- Remove emitAtopOp with NameNode*
- Pass JSOp to BytecodeEmitter::emitAssignment (modified)
- Add BytecodeEmitter::emitGetFunctionThis variant with offset
Based-on: m-c 1466000/{2-6}
