Moving generic metadata pattern cache out-of-line


(Joe Groff) #1

We currently emit generic metadata templates with space statically allocated inline for the runtime to emplace its metadata cache. This would prevent generic metadata patterns from being mapped read-only if we eliminate the relocations from the rest of the compiler-emitted structure. Now that we're putting an accessor function in front of the raw metadata runtime calls, I think we could allocate this space separately in the data segment and pass it as a separate parameter to swift_getGenericMetadata alongside the pattern pointer. Any objections?

On a similar note, we also emit a one-word invasive uniquing cache in nonuniqued metadata objects, used for things like metadata for imported C types where we don't have a single Swift TU to associate with the type. Could this also be moved out-of-line?

-Joe


(John McCall) #2

We currently emit generic metadata templates with space statically allocated inline for the runtime to emplace its metadata cache. This would prevent generic metadata patterns from being mapped read-only if we eliminate the relocations from the rest of the compiler-emitted structure. Now that we're putting an accessor function in front of the raw metadata runtime calls, I think we could allocate this space separately in the data segment and pass it as a separate parameter to swift_getGenericMetadata alongside the pattern pointer. Any objections?

You should just make this a (relative) pointer in the pattern header, but otherwise no, no objections.

On a similar note, we also emit a one-word invasive uniquing cache in nonuniqued metadata objects, used for things like metadata for imported C types where we don't have a single Swift TU to associate with the type. Could this also be moved out-of-line?

Sure, adding an extra load in the access path isn’t at all prohibitive.

John.

···

On Jan 26, 2016, at 4:39 PM, Joe Groff <jgroff@apple.com> wrote: