HomeWildfire Games

Use Symbols to store JS object references when serialising and delete…

Description

Use Symbols to store JS object references when serialising and delete ObjectIDCache

When serialising JS objects, we keep track of any encountered object, and serialize it only once. Any further serialisation instead stores an ID referring to the original object (essentially an opaque pointer).
The trouble of course is to have a unique, persistent identifier for such an object.
svn uses an ObjectIDCache, essentially a "JS Object -> ID" map (which internally is essentially a "JS heap pointer -> ID" map).

JS, since ES15, includes a "Symbol" primitive type, which is a unique, immutable identifier. They are also not iterable by for..in or GetOwnPropertyName or related.
This means they can be used to store the tag directly on the object (since it's impossible overwrite a user property).
Thanks to this, we can forgo ObjectIDCache in the serializers, and since following D2897 it becomes unused, we can delete it, along with the Finalization code it used.

Part of SM52 migration, stage: SM45-compatible changes.

Patch by: Itms

Tested By: Freagarach

Refs #4893

Differential Revision: https://code.wildfiregames.com/D3085

Event Timeline

vladislavbelov added inline comments.
/ps/trunk/source/simulation2/serialization/BinarySerializer.cpp
445

tagValue is int and the returning value is int. It might be a protentional dangerous place, because there might be tagValue equals to -1.

/ps/trunk/source/simulation2/tests/test_Serializer.h
1

Wrong year.

wraitii added inline comments.Dec 23 2020, 1:42 PM
/ps/trunk/source/simulation2/serialization/BinarySerializer.cpp
441

After working on D2746 a bit, I declare this bit "meh".
It's settings symbols as enumerable, which is wrong (even per the comment above). When hotloading, it can lead to the symbols getting picked up where we don't want them.

Further, obj might not be writable. This is trickier to fix, we'd probably want a fallback object somewhere.

I feel like we might need to rewrite this after all, but I'll see.

445

I believe the JS standard guarantees that this doesn't happen