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.
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.
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.
