> On Mar 14, 2017, at 2:16 PM, John McCall <[email protected]> wrote: > >> On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Mar 14, 2017, at 13:52, Greg Parker via swift-dev <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> On Mar 14, 2017, at 12:43 PM, Joe Groff <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hey Greg, what are the correct refcounting bits now to set in a global >>>>> statically-emitted heap object that shouldn't ever be released? >>>> >>>> For now use the same thing that stack-allocated objects use. I forget what >>>> the bit pattern is exactly. (I assume you are not in strictly read-only >>>> memory and can tolerate writes to the refcount word. We don't yet have an >>>> implementation for immortal read-only objects.) >>> >>> Oh wait, you *don't* want to use what stack-allocated objects use. They get >>> deinited without being deallocated, and I assume you want neither deinit >>> nor dealloc. Let me work this out. >> >> Wouldn’t it be okay to just emit it with an unbalanced retain? > > It's better if there's some way to make an object completely ref-count inert. > Often, the compiler only sees one side of a retain/release pair, like when > you return a constant NSString — you know locally that you're retaining a > constant string, but you're returning it to some context that has no idea > what it's getting. If the object is just unbalanced-retained, you have to > preserve the retain or else the caller might release it. (That's true even > if the imbalance is quite large — no fair crashing the program but only after > a function's been called 2^19 times! Imagine reproducing that...) Making the > object completely inert means you can just unconditionally say "hey, I know > R/R are no-ops on this value" and delete them as a peephole.
That's right. Unbalanced retain is the solution today. I expect a truly inert solution soon. -- Greg Parker [email protected] <mailto:[email protected]> Runtime Wrangler
_______________________________________________ swift-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-dev
