Type metadata and identity


(Jordan Rose) #1

Hi, all (but especially the perf team). ChrisW and I are working on importing Objective-C generics as Swift generics <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006790.html>, getting at least the bare minimum working. One interesting thing here is that Objective-C generics are type-erased, meaning that there isn't a different Class for, e.g. NSLayoutAnchor<NSLayoutXAxisAnchor *> and NSLayoutAnchor<NSLayoutYAxisAnchor *>. That means that the type metadata pointers for those two types will be identical.

Can anyone think of problems this will cause? Do we rely on different types having different metadata for anything other than downcasting? (See the proposal for a discussion of downcasting.)

Thanks,
Jordan


(Andrew Trick) #2

The optimizer might try to materialize a pointer metatype pointer from an AST type and emit direct comparisons with the ‘isa’ pointer. I don’t see why that would be a problem though, since the types are runtime equivalent anyway.

Andy

···

On Feb 23, 2016, at 1:51 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

Hi, all (but especially the perf team). ChrisW and I are working on importing Objective-C generics as Swift generics <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006790.html>, getting at least the bare minimum working. One interesting thing here is that Objective-C generics are type-erased, meaning that there isn't a different Class for, e.g. NSLayoutAnchor<NSLayoutXAxisAnchor *> and NSLayoutAnchor<NSLayoutYAxisAnchor *>. That means that the type metadata pointers for those two types will be identical.

Can anyone think of problems this will cause? Do we rely on different types having different metadata for anything other than downcasting? (See the proposal for a discussion of downcasting.)


(Jordan Rose) #3

Right. I can imagine missed opportunities for CSE or even devirtualization, but would not expect miscompiles or changes in formally observable behavior between -O and -Onone.

Jordan

···

On Feb 23, 2016, at 16:54 , Andrew Trick <atrick@apple.com> wrote:

On Feb 23, 2016, at 1:51 PM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Hi, all (but especially the perf team). ChrisW and I are working on importing Objective-C generics as Swift generics <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006790.html>, getting at least the bare minimum working. One interesting thing here is that Objective-C generics are type-erased, meaning that there isn't a different Class for, e.g. NSLayoutAnchor<NSLayoutXAxisAnchor *> and NSLayoutAnchor<NSLayoutYAxisAnchor *>. That means that the type metadata pointers for those two types will be identical.

Can anyone think of problems this will cause? Do we rely on different types having different metadata for anything other than downcasting? (See the proposal for a discussion of downcasting.)

The optimizer might try to materialize a pointer metatype pointer from an AST type and emit direct comparisons with the ‘isa’ pointer. I don’t see why that would be a problem though, since the types are runtime equivalent anyway.


(Andrew Trick) #4

If we do materialize the metatype, I think we could actually optimize NSLayoutAnchor<NSLayoutXAxisAnchor *> as if it were NSLayoutAnchor<NSLayoutYAxisAnchor *>. I think would only matter if we had swift extensions of one type that didn’t extend the other, right? …

extension NSLayoutAnchor where T : ProtocolThatNSLayoutXAxisAnchorConformsTo {
  // some additional overrides
}

Is that sort of type extension possible? I think we’re saved by this:
error: members of constrained extensions cannot be declared @objc

If this does turn out to be an issue, then maybe we can change the type system’s API so that the optimizer can’t ask for a metatype for an imported generic.

Andy

···

On Feb 23, 2016, at 4:55 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Feb 23, 2016, at 16:54 , Andrew Trick <atrick@apple.com <mailto:atrick@apple.com>> wrote:

On Feb 23, 2016, at 1:51 PM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Hi, all (but especially the perf team). ChrisW and I are working on importing Objective-C generics as Swift generics <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006790.html>, getting at least the bare minimum working. One interesting thing here is that Objective-C generics are type-erased, meaning that there isn't a different Class for, e.g. NSLayoutAnchor<NSLayoutXAxisAnchor *> and NSLayoutAnchor<NSLayoutYAxisAnchor *>. That means that the type metadata pointers for those two types will be identical.

Can anyone think of problems this will cause? Do we rely on different types having different metadata for anything other than downcasting? (See the proposal for a discussion of downcasting.)

The optimizer might try to materialize a pointer metatype pointer from an AST type and emit direct comparisons with the ‘isa’ pointer. I don’t see why that would be a problem though, since the types are runtime equivalent anyway.

Right. I can imagine missed opportunities for CSE or even devirtualization, but would not expect miscompiles or changes in formally observable behavior between -O and -Onone