4pull tree cleanup

[stewartoallen]

No description provided.

[tea-dragon]

For the deferred ops optimization, it would be even better if we could reliably skip the entire try/lock block by performing the if condition earlier. This would be nice for both performance and clarity -- I am not a big fan of our frequent use of null values as sentinals. Clearly it is possible to check "child != null" but in practice child is never null -- updateParentData is only ever called right after a method call on the same child object passed in.

The data variable is a little trickier because it is lazily instantiated for new nodes (or nodes that previously had no data attachments in their config and were later given one and then processed again, but that is an extreme corner case). The typical tree traversal has parent nodes that were previously processed by the same thread as child nodes - in such a case it is guaranteed that data will correctly appear as non-null or null. It wouldn't be safe to modify or examine, but it would be enough to tell whether the node had to be locked to process updates for it. It is less obvious whether this traversal is, or could easily be converted to, an actual invariant. TreeStates are pretty flexible with their processing stack. Given that most nodes don't actually have data and almost every case in terms of processing frequency allows the check to be safely made, it would be nice if someone could finish the theorem so to speak, but that's an issue for another day maybe.