3 ms·

Swift and Vala and any other eagerly reference counted language don’t have to worry about native C code squirreling away a reference to a GC’s object and not re

Swift and Vala and any other eagerly reference counted language don’t have to worry about native C code squirreling away a reference to a GC’s object and not responding to a GC marking callback (either because the mechanism doesn’t exist or because it isn’t used correctly). That’s an enormous difference in ABI.

neonsunset 3y ago
How would C track references for heap-allocated data originating from (A)RC-based language? I don't think what you say on .NET correlates with reality - you are not supposed to pass managed objects across FFI (you just can't, it won't let you unless you do unsafe cast shenanigans) - the correct way is to either marshal the data or use blittable representation (plain structs can be passed as is, either by reference or value, same goes for arrays/pointers of primitives). On the rare occasion where unmanaged code needs to keep a GC object alive, it is passed via special GCHandle but that's an exception not the rule. Swift has its own high level representation for such objects which are very much not FFI compatible. ARC in Swift is a feature that requires compiler involvement to work correctly, and its structs are not FFI compatible unless they are "trivial". Swift also has its own more advanced Swift Library Evolution ABI, which is strictly not C ABI you expect out of your regular library and has its own calling convention and semantics. Overall, there seem to be strange misconceptions about how these languages work so it would be best to check with the documentation first: .NET P/Invoke (FFI): - https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke https://learn.microsoft.com/en-us/dotnet/standard/native-int... - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/interop#linking https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Swift non-C ABI: - https://github.com/apple/swift/blob/main/docs/LibraryEvolution.rst https://github.com/apple/swift/blob/main/docs/LibraryEvoluti... - https://www.swift.org/blog/library-evolution/ https://www.swift.org/blog/library-evolution/ Swift ARC: - https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/ https://docs.swift.org/swift-book/documentation/the-swift-pr... - https://github.com/apple/swift/blob/main/docs/ARCOptimization.md https://github.com/apple/swift/blob/main/docs/ARCOptimizatio... (I don't actually know if any other other platform, besides Swift itself, implements Swift ABI support, but .NET is going to have it in .NET 9 - likely the first non-Swift platform to do so)
- pizlonator 3y ago
  Swift’s reference counting is exactly what C code on Apple’s platforms were already doing. And Vala’s is exactly what GObject code was already doing.
  - neonsunset 3y ago
    That's not C but Objective-C. From quick skim of the spec[0], it relies on macros and same autorelease pool. There is no free lunch in software engineering, only difficulties with accepting reality. [0] https://clang.llvm.org/docs/AutomaticReferenceCounting.html https://clang.llvm.org/docs/AutomaticReferenceCounting.html
    - pizlonator 3y ago
      It's both C and Objective-C. Objective-C's refcounting is exposed to C via CFRetain/CFRelease. Long before there was ARC (the thing you cite), the bulk of the NexTSTEP and then Apple frameworks were written with Objective-C code manually doing [obj retain]/[obj release] and C code manually doing CFRetain(obj)/CFRelease(obj). There was some doc somewhere telling you the protocol. Later, ARC came around to automate it for Objective-C code that opted in. ARC carefully mimicked the semantics of the protocol in that doc. And then later, Swift came along and mimicked the semantics of ARC. There is a free lunch for languages that use reference counting. That free lunch doesn't exist for GC'd languages, which introduce a semantics that is different from the ones that C code already uses. Sorry to burst your bubble.
      - neonsunset 3y ago
        If reading documentation and looking into implementation details doesn't help, I welcome you to measure ARC overhead and observe the numbers with your own eyes at least once, especially in multi-threaded scenario. Might also read one of the previously posted links still, surely something will work eventually.
        3y ago

neonsunset 3y ago

How would C track references for heap-allocated data originating from (A)RC-based language? I don't think what you say on .NET correlates with reality - you are not supposed to pass managed objects across FFI (you just can't, it won't let you unless you do unsafe cast shenanigans) - the correct way is to either marshal the data or use blittable representation (plain structs can be passed as is, either by reference or value, same goes for arrays/pointers of primitives). On the rare occasion where unmanaged code needs to keep a GC object alive, it is passed via special GCHandle but that's an exception not the rule. Swift has its own high level representation for such objects which are very much not FFI compatible. ARC in Swift is a feature that requires compiler involvement to work correctly, and its structs are not FFI compatible unless they are "trivial". Swift also has its own more advanced Swift Library Evolution ABI, which is strictly not C ABI you expect out of your regular library and has its own calling convention and semantics. Overall, there seem to be strange misconceptions about how these languages work so it would be best to check with the documentation first: .NET P/Invoke (FFI): - https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke https://learn.microsoft.com/en-us/dotnet/standard/native-int... - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/interop#linking https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Swift non-C ABI: - https://github.com/apple/swift/blob/main/docs/LibraryEvolution.rst https://github.com/apple/swift/blob/main/docs/LibraryEvoluti... - https://www.swift.org/blog/library-evolution/ https://www.swift.org/blog/library-evolution/ Swift ARC: - https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/ https://docs.swift.org/swift-book/documentation/the-swift-pr... - https://github.com/apple/swift/blob/main/docs/ARCOptimization.md https://github.com/apple/swift/blob/main/docs/ARCOptimizatio... (I don't actually know if any other other platform, besides Swift itself, implements Swift ABI support, but .NET is going to have it in .NET 9 - likely the first non-Swift platform to do so)

pizlonator 3y ago
Swift’s reference counting is exactly what C code on Apple’s platforms were already doing. And Vala’s is exactly what GObject code was already doing.
- neonsunset 3y ago
  That's not C but Objective-C. From quick skim of the spec[0], it relies on macros and same autorelease pool. There is no free lunch in software engineering, only difficulties with accepting reality. [0] https://clang.llvm.org/docs/AutomaticReferenceCounting.html https://clang.llvm.org/docs/AutomaticReferenceCounting.html
  - pizlonator 3y ago
    It's both C and Objective-C. Objective-C's refcounting is exposed to C via CFRetain/CFRelease. Long before there was ARC (the thing you cite), the bulk of the NexTSTEP and then Apple frameworks were written with Objective-C code manually doing [obj retain]/[obj release] and C code manually doing CFRetain(obj)/CFRelease(obj). There was some doc somewhere telling you the protocol. Later, ARC came around to automate it for Objective-C code that opted in. ARC carefully mimicked the semantics of the protocol in that doc. And then later, Swift came along and mimicked the semantics of ARC. There is a free lunch for languages that use reference counting. That free lunch doesn't exist for GC'd languages, which introduce a semantics that is different from the ones that C code already uses. Sorry to burst your bubble.
    - neonsunset 3y ago
      If reading documentation and looking into implementation details doesn't help, I welcome you to measure ARC overhead and observe the numbers with your own eyes at least once, especially in multi-threaded scenario. Might also read one of the previously posted links still, surely something will work eventually.
      - 3y ago