<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 13, 2016, at 5:14 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Oct 13, 2016, at 2:04 PM, Alexis <<a href="mailto:abeingessner@apple.com" class="">abeingessner@apple.com</a>> wrote:<br class=""><br class="">Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and AArch64? Would this then mean any attempt to use Swift in kernel-space requires a distinct ABI?<br class=""></blockquote><br class="">That's correct, but we'd likely already have to have a separate "kernel" ABI due to our assumptions about spare bits in pointers. It also seems unlikely to me that kernel developers would want to use our refcounting scheme as is.<br class=""></div></div></blockquote><div><br class=""></div><div>True, but the types being discussed here seem to mostly be language features that are implicitly falling back to reference counting when escape analysis fails. And specifically the tagging you’re proposing is for the cases where some special analysis <i class="">passes </i>and we can avoid the ref-counting machinery, right? Sounds like exactly the things they want. Although perhaps if they want to<i class=""> always</i> avoid the ref-counting machinery, then we can actually have <i class="">more aggressive</i> pointer tagging tricks in the kernel ABI. </div><div><br class=""></div><div>Well, as long as we’re aware that this is more complexity we’re adopting, seems fine.</div><div><br class=""></div></div></body></html>