<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2017, at 7:35 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Mar 16, 2017, at 4:23 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""></blockquote></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Mar 14, 2017, at 3:53 PM, Greg Parker via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2017, at 2:16 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2017, at 5:08 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2017, at 13:52, Greg Parker via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2017, at 1:34 PM, Greg Parker via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 14, 2017, at 12:43 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class="">Hey Greg, what are the correct refcounting bits now to set in a global statically-emitted heap object that shouldn't ever be released?<br class=""></blockquote><br class="">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.)<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">Wouldn’t it be okay to just emit it with an unbalanced retain?<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">That's right. Unbalanced retain is the solution today. I expect a truly inert solution soon.<br class=""></blockquote><br class="">Cool. Do you think we'd be able to avoid atomic barriers on inert objects, or would that unfairly impact freeable objects?<br class=""></blockquote><br class="">Greg is the right person to answer this for certain, but retain and release use a load + exchange pattern, and inertness will presumably be testable based purely on the initial load.</div></div></blockquote><br class=""></div><div>Oops, dropped my reply somewhere. Yes, that's correct. The only barriers are the store-release in swift_release and the matching acquire before deinit. Truly inert objects would perform neither of those. They would perform the load and then shortcut out at the "this object is unusual" bit test before the incremented store.</div><br class=""><div class="">You can initialize your objects with a refcount field of `uintptr_t(1)` for now. That's the same value used for newly-allocated objects. Note that the `1` is not the strong retain count.</div><div class=""><br class=""></div><div class="">Is this going in the compiler's codegen somewhere? We should have a test and a big comment in RefCount.h for the dependency, assuming it can't be easily handled automatically at build time, because these values will certainly change in the future. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>