We need to check whether type objects are marked over and over during GC, regardless of how many type objects there actually are. TypeObjects are currently malloc'ed individually and store their mark bits as a field, which has the potential for lots of fragmentation and cache misses.

Make TypeObject a GC thing, and do some other refactoring: - Allow singleton type objects (representing exactly one JS object) to be destroyed on each GC (in addition to being lazily constructed, as last week's refactoring did) if the conservative GC does not find a pointer to them, and allocate their data from the analysis pool rather than via malloc. - Track per-allocation-site type objects in a per-compartment hashtable (similar to what we do for JSON/singleton type info). This cuts the size of TypeObject significantly, and removes a mostly-unused pointer from JSScript. Allocation of such objects may slow down, the fix for that is to inline creation of objects, arrays etc. in the jitcode. This also removes the quadratic behavior seen with scripts containing tons of object/array initializers. Another tests-pass push (at least in the shell), still need to see how this affects memory.

Can this be closed?