swift_tailRealloc

HeapObject *swift_reallocObject(HeapObject *, size_t) should be a Swift runtime entry point. The runtime should be responsible for knowing whether an object's address is significant at runtime. The caller is still responsible for guaranteeing that the object contents are bitwise takeable.

One of the runtime checks will be for be for the existence of associated objects. @Arnold points out that it could be a slow check because the ObjC runtime doesn't have a fast entry point yet. If that's the case, we have a few options for proceeding:

  1. Keep this API underscored for now, and comment that users of the API need to guarantee their ManagedBuffers aren't exposed to ObjC.

  2. Add a compiler attribute that can be used in ManagedBuffer's definition to that prevents the runtime from allowing associated objects. The runtime support exists, but the compiler needs to be taught to initialize a metadata bit for that attribute.

  3. File a bug against the ObjC runtime to add a fast "hasAssociatedObject" check callable from the Swift runtime. (/cc @gparker42)

Which of these options to pursue probable depends on your timetable for using the API and whether the measured performance overhead of the associated object check is unacceptable to you.

Thanks, after a chat in person we came up with a new plan which and I have now updated the implementation: implement ManagerBuffer.reallocated to allow realloc'ing the storage by weissi · Pull Request #19421 · apple/swift · GitHub .

Sadly, that means that at the moment, tail reallocation won't work on Darwin. The reason is that we would need to check if a given object has ObjC side tables or associated objects which (at the moment) cannot be done efficiently.