With strings being allocated into the nursery, we run out of nursery space sooner, so the count of objects getting tenured means something different. (In fact, right now it's a hardcoded 3000).

Similarly, the decision of whether or not to even consider pretenuring depends on why we're collecting the nursery. If the store buffer fills up, we might pretenure independent of the promotion rate. But objects and strings use the store buffer separately; you could fill up the store buffer with object tenured -> nursery edges without having any string tenured -> nursery edges, or vice versa.

A relatively straightforward way to spearate these out would be to have separate nurseries for strings and objects. Perhaps separate store buffers, too? Though if you put something in the whole cell buffer for both an object store and a string store, it's kind of nice to only have one entry. Perhaps the whole cell buffer could stay shared.

At least having a separate string nursery would be fairly simple in some ways. You would trace the roots and the regular nursery. But any pointer pointing into the string nursery you mark but don't need to follow any, so this could be an optimisation.

(In reply to Paul Bone [:pbone] from comment #1)

At least having a separate string nursery would be fairly simple in some ways. You would trace the roots and the regular nursery. But any pointer pointing into the string nursery you mark but don't need to follow any, so this could be an optimisation.

Sadly not true. There are JSString variants that contain string pointers: ropes, dependent strings, and the weirdo "undepended" strings.

Writing up this description mostly just to remind myself:

An undepended string is produced when you have the string "ABC", construct a dependent string "AB" that points into the original string, then create a dependent string of your "AB" string that contains only "B". "B" will keep "AB" alive, which will keep "ABC" alive, and everything is all fine until some jerk comes along and says it wants "AB" NUL-terminated. So you allocate a new chunk of memory for it, but "B" is still pointing at the original "ABC" memory but only keeping "AB" alive. "ABC" could die unless "AB" keeps it alive, but "AB" doesn't use "ABC" anymore. So "AB" turns from a dependent string to an undepended string, with an only-for-GC pointer to "ABC".

...only this case is pretty rare, because the normal path for creating a dependent string makes it depend on the ultimate base string (so "B" depends on "ABC", not "AB"). But our crazy flattenInternal implementation can produce dependents of dependents.