Single entry slot map

[aardvark179]

Single entry slot map

This is a stacked PR on top of

• Reduce indirection and memory overhead for slot maps. #1782
• Start to factor out slot map container #1783

This introduces a single-entry slot map to take the common case of a single property from:

graph LR
Object["ScriptableObject"]
Map["SlotMap"]
Array["Slot[]"]
Slot1["Slot"]
Object1["ScriptableObject"]
Map1["SlotMap"]
Array1["Slot[]"]
Slot2["Slot"]
Object --> Map --> Array
Array --> Slot1
Object1 --> Map1 --> Array1
Array1 --> Slot2

Loading

to:

graph LR
Object["ScriptableObject"]
Map["SingleEntrySlotMap"]
Slot1["Slot"]
Object1["ScriptableObject"]
Map1["SingleEntrySlotMap"]
Slot2["Slot"]
Object --> Map --> Slot1
Object1 --> Map1 --> Slot2

Loading

This saves 48 bytes on any object with a single slot.

[aardvark179]

Rebased after merge of #1782.

[gbrail]

In theory, "compute" is also used to replace an existing slot, rather than add a new one. I don't know how much that happens in actual situations, but there are plenty of places in the codebase where it happens. With this implementation, in that case we'll upgrade to a "real" EmbeddedSlotMap, but then it still may have a size of one.

Would it complicate things a lot to support that use case? If not, should we try it? I would also be open to the idea that this would be a premature optimization.

[aardvark179]

I chose to always promote there because I figured that a map which is mutated is likely to continue to be mutated, and it made it easier to think about the multithreaded cases.

Removing a slot also causes the map to be promoted as that maintains a strict type lattice of slot map types (we never demote a map). I tried to support that sort of thing initially but it made the code much more complex and was rarely triggered in my testing so I went for the simpler approach seen here.

Ultimately I think we should separate values and slot descriptors, and make the latter immutable. That would open up some good optimization opportunities in both the interpreter and compiler, and would lI think save quite a bit of memory.

[gbrail]

OK -- looks good to me -- thanks!