Repository navigation
implement "dynamic drop" semantics using flags on the stack rather than zeroing #5016
Description
Activity
This seems doable and straightforward. It's basically adding another bit to track per variable ("was moved") which uses intersection on join when propagating.
However, there is another approach that @pcwalton and I have toyed with from time to time, which is saying that when you move things, the destructor for the moved thing runs "early"---basically at the point where control flow on the non-moved path (if any) rejoins the control flow from the moved path. The idea here was to remove the need to zero 100% of the time. However, I am not sure if that idea (early destructing) is such a good idea, because it seems hard to specify and predict, whereas the current semantics (destructors run at the same time unless moved) is easier.
So if we keep current semantics, then I think something like this seems like a good optimization. In principle we could do better and identify nodes in the CFG where, upon entering the node, we know the value will be moved (this is what liveness will be computing, actually). Then we could avoid zeroing as long as we dominate the node. That might be trickier though given the way failure and unrolling works, so maybe it's better to only optimize the case where the variable declaration is such a node.
http://llvm.org/docs/LangRef.html#llvm-lifetime-end-intrinsic may also be interesting
Nominating for milestone 1, well-defined.
Accepted for well defined. This needs to be documented.
I don't think the alternative would necessarily be harder to specify and predict. It's basically dynamic vs. static transfer of ownership. With the current rule, a variable's destructor is run at the end of the scope it was declared in, unless ownership of it was dynamically transferred to an inner scope. With the alternative rule, referring to the variable in an inner scope statically transfers ownership of it to that inner scope. The compiler already uses the latter rule to determine when a variable is legal to access, so the programmer has to think about it (if not, the compiler will make her). The alternative would make destructors follow the same rules. Currently you can have points in the code where the compiler won't let you access a variable but the variable's destructor may not have been run, which might be unintuitive itself.
Current plan (based on meeting discussion) is to have the compiler issue an error if there are ever two control flows that meet where one does a move and the other does not, so that this issue becomes a moot point. I am in the process of preparing a pull request taking some steps in this direction.
I'm somewhat working on this, btw. Also, it will affect the semantics of what moves are legal, particularly around vectors, since in those cases the compiler will not be able to determine statically which indices have been moved and which have not. I imagine we'll just disallow moves from like
let x = vec[y]and instead offer a method likelet x = vec.move(y)wheremoveis afn(self)method.Thinking a bit more, there is no need for
fn(self)method. Something likepopetc will suffice, particularly combined withswap:impl<T> ~[T] { fn remove(&mut self, index: uint) -> T { assert!(index < self.len()); if (index != self.len() - 1) { self.swap(index, self.len() - 1); } self.pop(); } }FWIW, that method currently exists:
.swap_remove.@huonw that's right, I knew I'd seen this somewhere :)
cc me
This interacts with the meaning/utility of the
std::ptr::read_and_zero_ptrfunction, right?I've been playing with that function recently in attempts to prototype some hypothetical finalization APIs. So I am curious to know what would replace it.
If a struct currently carries a
~T, I believe I can useread_and_zero_ptrto zero out that reference and keep that destructor for~T(and thus forTitself) from running.What is the replacement for that?
(Or should the struct field use
Option<~T>instead of~Tand thus I would be able to swap inNoneto prevent a destructor for~Tfrom running when the struct is destroyed?)44 remaining items
I expect it to land this year.
On Wed, Apr 06, 2016 at 05:39:55PM -0700, Ivan Smirnov wrote:
@pnkfelix Thanks for clarifying! Didn't mean to sound any negative, mostly just wondering if it's wise for library developers to assume this will land in some (finite) time and make their choices accordingly :)
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#5016 (comment)Reacted by Ivan Smirnov, Scott Olson, Raphael Cohn, gabomgp and Alexander Bulaev🎉
Reacted by Ivan Smirnov, Paul Colomiets, Michael Pankov, Levi Webb, Scott Olson, Erin and Finn BearI have some code that spends a measurable amount of time checking for drop flags (there's an inner loop which drops an
Option<Box<...>>which is virtually alwaysNone), and so I'm kind of wondering if we have a ticket for the other side of this, where we delete POST_DROP_U8 and stop generating code in drop methods to check for it. Do we have a tracking ticket for that?Incidentally, this ticket is currently the tracking issue for the POST_DROP_U8 constant; maybe that should be repointed now that this ticket is closed?
(Tracking issue for RFC 320.)
Original Description
The current liveness check has a concept of "alive" and "maybe dead", so I'll just describe this in terms of a hypothetical "move optimization pass" (although liveness can probably be extended with "surely dead").
Hypothetical move optimization pass:
In each scope where they exist, all variables are given an associated boolean representing whether they were certainly moved from. Moving from a variable in a scope marks it as such for that scope. This can be bubbled up if and only if the variable is also moved from in every other branch.
If the compiler can bubble this up to the scope where the variable is declared, the drop glue can be omitted and all moves from that variable do not need to zero it.
This can probably be extended to fields too, but I'm not sure on what the semantics would be.
@nikomatsakis: does this look like something that would be reasonable to implement (probably as part of liveness)? It doesn't actually need to bubble it up to be useful - even if it only worked in a local scope, it would allow the destructor of the
savevariable in the TreeMapsplitandskewfunctions to be omitted (since it's moved from in the same scope where it's declared) and that would be a big performance win.