Optimization in KDE Base
Decrease memory usage for JS objects/values by a third (48->32 bytes on 32-bit), and tune the allocator properly, giving a ~10+% speed up on 32-bit, and a huge speed up on 64-bit, since it was previously not configured properly at all.
This is heavily based on JSC revisions 21017, 21018, 21019, 21025, 21029, 21031, 21047, 21048 which are in turn heavily based on Chris Hyde's work in our kjs-tweaks branch; however, this does not introduce what I consider to be questionable GC semantics, which make the allocator abort/crash if the object size is too big for its liking (OK, OK. We still abort on objects ~64kb in size or more.
But surely no one has those. Right? Right!?)
Discussed with Harri, and regression tested twice, once w/normal allocator, and once with additional usage of oversize allocator forced, since it's barely used at all otherwise.
In more detail:
- Move lots of stuff in RegExp object into d-pointer
- Remove the two modes of marking in KJS::List, and just mark them globally, but purge them aggressively when possible.
This is the only SIC bit, but it also simplifies semantics and makes the use of KJS::List less error-prone
- Store the size of array objects with data, to shrink them
- Get rid of threadsafe-dtor bit, as we don't need it.
- Tuck localInjected bit with the property map
- Make property maps smaller by taking advantage of the fact that the single-entry and table modes are disjoint, and hence can shared some storage via a union
- Make the allocator work with well-aligned, fixed-size blocks, to make it possible to easily find heap metadata from the pointer.
This also simplifies checking of pointers at stack scan.
- Using the above, move the mark bits into heap metadata, finally fixing the 3-bits-eating-4-or-8-bytes insanity
- Implement a completely new oversize allocator that is capable of working with mark bits.
This is a simple bitmap'd allocator which is not very fast on its own, but is designed carefully to not intefere with the fast fixed-size allocator's operation and performance, and to do very little work when there are just a few oversize objects around, which is the common case for KHTML.