Stable Memory Location for Components

[W4RH4WK]

Some time ago we discussed the feature of having stable memory locations for certain components on Gitter. The discussion sprung from the idea of combining a scene graph with entt. In my proof-of-concept implementation I used std::unique_ptr to guarantee correct memory access. However, this creates another indirection which could be avoided by having entt not relocate certain components.

https://github.com/W4RH4WK/EnTT-SceneGraph/blob/46b9acb85422c8ca2d4d59e0b65985ea4b798a72/entt_scene.cpp#L154

Since I could not find an issue / discussion related to it, I decided to open this one to keep track of it.

[skypjack]

Before replying, is it a problem if I turn this issue in a GH discussion? It seems to me better suited for that kind of tools.

[W4RH4WK]

No, of course not. Feel free.

[skypjack]

Nvm. Apparently, the convert button disappeared in the meantime. 🤷‍♂️

---

Some time ago we discussed the feature of having stable memory locations for certain components on Gitter.

Let's discuss this here until we can convert the issue to a discussion again.
So, what you want is to have a pool where references aren't invalidated in any case when you add/remove new instances of a given type, right?
Because it's easy to have it (and actually planned) for when a component is added, while having true stable references upon deletion may take more work (but it's still possible).

[W4RH4WK]

So, what you want is to have a pool where references aren't invalidated in any case when you add/remove new instances of a given type, right?

Yes.

Maybe we also need a way to re-organize such a pool. Assuming the pool lives for a long time, with lots of references added / removed, fragmentation may occur and degrade performance. Alternatively we could just create a new pool and re-add everything that is still alive. Either way, such re-organization would be triggered by the user during a maintenance phase, invalidating all references.

[skypjack]

Assuming that the pool is paged and therefore additions aren't a problem, deletions can leave holes here and there and you can invoke a method to fill them at the end of a tick.
It would be completely in charge to the user to find the best time for that, but it makes perfectly sense to me.
My only concern is if this is better than using entities to get the components rather than storing aside references. Probably the answer is: it depends. On the number of reference, on the number of additions/deletions, and so on...

[skypjack]

I'm working on some changes that should make it possible to have stable references. The idea is to use some unused bits in the pool and introduce a sort of component version. EnTT won't update it out-of-the-box because there are many uses for that. However, it can be used to to track reference invalidation and therefore to address this issue.
I'll put an example in the test dir if everything works as expected. 👍

[skypjack]

Short update. There will be probably two tools that solve slightly different problems.
The first one is the component version combined with a pagination of the component pool, as described above.
The other one is a tombstone model for truly stable references. A pretty interesting one, with its pros and cons.
More about these soon. 🙂

[skypjack]

Update: master contains the changes required for pointer stability when assigning components.
Working on a soft remove that doesn't trigger a swap-and-pop operation in the pool.

[skypjack]

I've still to write the documentation but branch wip contains all changes required to have full stable pointers.

[W4RH4WK]

Great to hear. I'll update my scene graph example once it's in master.

[skypjack]

Landed on master. 👍 Wiki updated.
I close the issue but feel free to drop here any question in case.

[W4RH4WK]

Looks good. I've just updated my scene graph example.

https://github.com/W4RH4WK/EnTT-SceneGraph/blob/master/entt_scene.cpp#L155-L176

[skypjack]

Great. Does it work as expected? Pagination and tombstones should make components fully stable.
More will come in future but I want this feature to settle before adding other stuff on top of it.

[W4RH4WK]

I haven't done thorough testing, but it looks good so far. Thanks. I'll let you know if anything comes up.