The current situation seems incorrect, especially given the behavior of CrossOriginWrapper and XrayProxy. Currently it doesn't matter, but it probably will in the future.
This isn't an issue right now, since it can't ever happen outside of sandboxes, which content can't use. But if it could, it could get a pure CrossCompartmentWrapper to a Location object, which is bad.
I'm adding asserts about when we do and don't have a Location object behind the wrapper, and this case was hitting them. What we do here doesn't so much matter given how this stuff all works. On the one hand, statically using a restrictive policy is slightly more defense-in-depth. On the other hand, if this stuff is broken we're screwed in much more serious ways than content reading chrome locations, and using a consistent wrapper scheme allows us to make stronger asserts and assumptions.
I opted for stronger assumptions and more understandable security code. If Blake feels strongly though, I could go the other way and sprinkle '|| isChrome(obj)' throughout the asserts though.
This patch pushes our null results for non-run tests before running other tests
so that when we do not try to update the progress bar after we finish running.
--HG--
extra : rebase_source : 02e53cddcab4c5898ef2636f78c806509ae33dcf
HashMap and HashSet only expose Entries through Ptr and Range, except for one
variant of put. They also don't expose the default size they use if you call
init() without an argument. These weirdnesses seem to be interface carried over
from the old jsdhash.
The first oddness is unused and can be removed, the second should simply get
exposed to make it easier to wrap HashMap and HashSet.
--HG--
extra : rebase_source : e1432a9af189229f379158ba0529956ddbf5f234
The patch shrinks the API presented in jsxdrapi.h down to 4 functions to
encode/decode scripts and interpreted functions to/from the memory. The
newly introduced implementation header vm/Xdr.h replaces the former
JSXDRState with the template class XDRState parametrized by the enum
type with two constants, XDR_ENCODE and XDR_DECODE. This way a compiler
can fully eliminate the former runtime checks for the decoding/encoding
mode. As a drawback this required to explicitly instantiate the xdr
implementation as I do not want to put all the xdr code to header files.
The memory-only XDR allows to avoid coping filename and to-be-atomized
chars to a temporary buffer as the code can just access the buffer
directly. Another change is that new XDRScript takes as a parameter its
parent script. This allowed to avoid keeping filename in XDRState and
simplify the filename management.
Another change is the removal of JS_HAS_HDR. As CloneScript uses XDR to
copy a script, JS_HAS_XDR cannot be disabled.
--HG--
rename : js/src/jsxdrapi.cpp => js/src/vm/Xdr.cpp
extra : rebase_source : f8f1536a86b7c3fe7296a16b6677bd21664af98a
The patch shrinks the API presented in jsxdrapi.h down to 4 functions to
encode/decode scripts and interpreted functions to/from the memory. The
newly introduced implementation header vm/Xdr.h replaces the former
JSXDRState with the template class XDRState parametrized by the enum
type with two constants, XDR_ENCODE and XDR_DECODE. This way a compiler
can fully eliminate the former runtime checks for the decoding/encoding
mode. As a drawback this required to explicitly instantiate the xdr
implementation as I do not want to put all the xdr code to header files.
The memory-only XDR allows to avoid coping filename and to-be-atomized
chars to a temporary buffer as the code can just access the buffer
directly. Another change is that new XDRScript takes as a parameter its
parent script. This allowed to avoid keeping filename in XDRState and
simplify the filename management.
Another change is the removal of JS_HAS_HDR. As CloneScript uses XDR to
copy a script, JS_HAS_XDR cannot be disabled.
--HG--
rename : js/src/jsxdrapi.cpp => js/src/vm/Xdr.cpp
The patch shrinks the API presented in jsxdrapi.h down to 4 functions to
encode/decode scripts and interpreted functions to/from the memory. The
newly introduced implementation header vm/Xdr.h replaces the former
JSXDRState with the template class XDRState parametrized by the enum
type with two constants, XDR_ENCODE and XDR_DECODE. This way a compiler
can fully eliminate the former runtime checks for the decoding/encoding
mode. As a drawback this required to explicitly instantiate the xdr
implementation as I do not want to put all the xdr code to header files.
The memory-only XDR allows to avoid coping filename and to-be-atomized
chars to a temporary buffer as the code can just access the buffer
directly. Another change is that new XDRScript takes as a parameter its
parent script. This allowed to avoid keeping filename in XDRState and
simplify the filename management.
Another change is the removal of JS_HAS_HDR. As CloneScript uses XDR to
copy a script, JS_HAS_XDR cannot be disabled.
--HG--
rename : js/src/jsxdrapi.cpp => js/src/vm/Xdr.cpp
This part removes the usage of JSContext* during the finalization and
when sweeping the compartments. That required to change quite a few
methods in type inference, jit and debugger implementation to take a
FreeOp rather than JSContext pointer. In turn that also often required
to replace cx->compartment usage with extracting the compartment from
the passed objects or pass the compartment explicitly. On the plus side
it allowed to remove fallible compartment enter code in methods that
could be called during finalization.
This parts removes the usage of JSContext* during the finalization in
Web Workers and JS shells implementations. With this chnages JSContext * is only
accessed during the finalization in the SpiderMonkey implementation.
This part changes the signatures for various finalization API to take
not JSContext* but rather either JSFreeOp structure or its
library-private counterpart FreeOp. These structures wrap parameters
that are passed to the finalizers removing most of explicit dependencies
on JSContext in the finalization code.
Currently to serialize principals stored in JSScript we have a rather complex
schema. First there is the transcode callback that the embedding must provide
to transcode principals using XDR API. Second we use rather complex glue code
to implement that callback in terms of writing/reading nsIObjectOutputStream/
nsIObjectInputStream. This glue code is duplicated in 3 places. All this can
be avoided if we simply delegate transcoding of principals to the caller. In
addition, at least in the case of the cached startup scripts we do not even
need to transcode the principals as the the cached scripts always have the
system principal so we can skip all the transcode complexity there.
The patch implemnts this idea. In particular, the code in JS engine
responsible for transcoding of principals is replaced by the single API
function JS_XDRSetPrincipals that the embedding can use to set principals for
decoded scripts and functions. Then the startup cache uses this to set the
principals for the decoded script to the system principals. The other two
places in nsJSContext::Serialize and XBL_SerializeFunction that need to
serialize principals together with a function or script now uses common
utilities in nsXPConnect so the serialization complexity resides in the single
place.
Currently the GC finalizes on the background thread only objects with null
JSClass::finalize. However, this implies that any object that uses
JS_FinalizeStub for the finalizer would be prevented from the background
finalization.
To fix this the patch removes JS_FinalizeStub replacing it with NULL in all
cases when the class has no custom finalizer. For style consistency the patch
also removed the usage of JSCLASS_NO_OPTIONAL_MEMBERS in the static
declarations as the compiler fills the missing fields with null in any cases.
Now that all of the marking interface users use indirect marking, we can pass
through the indirection internally and stop passing every object through the
stack.
It is possible in several places to have unconstrained client objects as the key
of a HashMap/HashSet. For generational and compacting GC, we will need to move
these objects in memory. This means we will need to remove and re-insert these
keys in a new location, during GC. Because we cannot safely allocate memory
for this, we need a specialized algorithm inside the HashTable itself.
Now that the marking indirection work is complete, this is no longer used and
should be removed.
--HG--
extra : rebase_source : e8116e9680c5a2005d0f9e6aea774b292cdca59c
It is possible in several places to have unconstrained client objects as the key
of a HashMap/HashSet. For generational and compacting GC, we will need to move
these objects in memory. This means we will need to remove and re-insert these
keys in a new location, during GC. Because we cannot safely allocate memory for
this, we need a specialized algorithm inside the HashTable itself.
Extensions such as MemChaser would really like an easier to parse and more
complete record of GC events than what can be gleaned from the message console.
This patch adds GC and CC observer messages formatted as JSON containing
detailed statistics.
In just 2 cases where JSPrincipals::codebase is used it can be reconstructed from the values stored in the associated nsJSPrincipal. In addition the patch makes nsJSprincipals to inherit both from nsIPrincipal and JSPrincipals allowing to use static_cast to convert between nsIPrincipal and JSPrincipals pointers and to drop many cases of manual JSPrincipal reference counting.
The private pointer is the only pointer update during GC marking that can invoke
unrelated code. If this code triggers a write barrier, then this will recurse.
This patch adds a way to update private pointers without triggering a barrier,
explicitly for use by the GC during marking.
