[webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

[Darin Adler]

The arguments about abandoning PassRefPtr for arguments entirely are attacking a straw man. We know PassRefPtr offers an important optimization and do not want to drop that!

On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote:

> (1) Use PassRefPtr for every parameter that takes ownership.

I still think this is the appropriate rule, and always have, but I think “takes ownership” is not defined to my satisfaction.

> Pro (of using PassRefPtr for every parameter that takes ownership):
>    Bright-line rule; fairly clear how to apply it.

This is where my problem comes in. I am not sure what the bright-line rule is.

Generally, in the DOM, the rule is that all reachable objects need to be kept alive, so reference counting is used to implement reachability, which does not match with my sense of the word ownership.

For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line:

    a) Hands off ownership to what could possibly be the sole owner in most code paths.
    b) Keeps a reference to the object after the function completes in most code paths.
    c) Takes a reference to the object at least once in most code paths.

    d) Hands off ownership to what could possibly be the sole owner in some code paths.
    e) Keeps a reference to the object after it completes in some code paths.
    f) Takes a reference to the object at least once in some code paths.

Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all?

Editing operations that are undoable often meet (b) but not (a). It’s confusing to me that editing operations want to “take ownership” of arguments. To make editing undoable the undo machinery may have to reference these objects, but it may also have to reference objects as well, perhaps the document or other elements. It’s not clear to me that requesting editing by passing arguments that specify where in the document the edit should take place means that the function takes ownership of those arguments.

If we tell the document which is the currently active title element by calling setTitleElement, the function meets (b) but not (a).

Similarly, some functions call out to operations that could cause the last owner for one of their arguments to dereference the object. They are likely to fit into category (c) or (f). In a sense the caller does have to pass ownership of the object, because the operation can only be successfully done if the function takes ownership to make sure the object does not disappear while the code is working with it.

> Con (of using PassRefPtr for every parameter that takes ownership):
>    Possible accidental self-zeroing bugs.

I think the “possible” adjective here makes this sound like a smaller problem than it is. Alexey and I have both seen multiple examples of this, particularly in contexts like constructor initialization lists where the prp idiom does not work well.

> Con (of abandoning PassRefPtr for function arguments entirely):

>     Possible accidental freed memory access bugs.


I think the reverse of this Con is one of the stronger Pro arguments for using PassRefPtr even more for arguments rather than my proposal to use it less. Object lifetime mistakes are much less likely when raw pointers are kept to an absolute minimum. I thought about this when reviewing the design of Automatic Reference Counting. The ARC design largely eliminates raw pointers for Objective-C objects.

I tried to find the examples that bother me. Here are some DOM examples where the term ownership seems wrong, and it’s more about reachability:

HTMLCollection::create: Does a collection own the node it is rooted in?
MessageEvent::initMessageEvent: Does a message event own the source DOM window?
Range::create: Does a range own the document its nodes are in and the nodes that are used to specify the endpoints?
Storage::create: Does a storage object own its storage area?
UIEvent::create: Does an event own its abstract view?

Here are some examples that are not purely DOM reachability that I find confusing:

Document::setTitleElement: Does a document own its title element?
FrameLoaderClient::dispatchWillSubmitForm: Does communication of a pending form submission involve passing ownership of form state?

I couldn’t quickly find other examples, but I have a vague sense that there are some that are even more confusing.

    -- Darin