This will mostly prevent us from having to reason about a priori thresholds for sparse array logic. If in doubt, JSC should be able to just allocate a large contiguous array and leave it to the GC to figure out whether or not that was a good idea. That might imply that the GC should also be able to create sparse maps as needed. Most likely the best way to do it will be that if the GC detects that an array would benefit from a sparse map and that array doesn't already have a sparse map, then it should defer the sparse map creation. It can be done as part of sweeping, or something. I'm marking this as depending on https://bugs.webkit.org/show_bug.cgi?id=100827. Really it's related to the other bug. I want to first bump up the sparse map size threshold and then later worry about the heuristics to make it safe-for-space in all of the various pathological corner cases.
Created attachment 171595 [details] the patch
Comment on attachment 171595 [details] the patch Ahhh!! Never mind. I posted this patch to the wrong bug.
FWIW, I think we should apply the same logic to named property backing stores.
(In reply to comment #3) > FWIW, I think we should apply the same logic to named property backing stores. We'd need to deal with structure implying backing store size