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

[Adam Barth]

I've fixed many a security bug cause by not refing local variables.
Generally, you need to ref your local variables if any function you call can
end up executing JavaScript (and many can).  If you're not sure, please feel
encouraged to ask around.

Adam
 On Jun 18, 2011 8:54 PM, "Darin Adler" <darin at apple.com> wrote:
> 1:
>
> Recently, Alexey has encouraged me to use PassRefPtr less for function
arguments.
>
> The PassRefPtr optimization pays off when the object in question is
possibly being handed off from one PassRefPtr to another. For an argument,
that can happen in two ways: 1) The argument can be the result of a function
that returns a PassRefPtr. 2) The argument can be the result of calling
release a local or data member that is a RefPtr. In both of those cases, we
are transferring ownership.
>
> Mechanically speaking, PassRefPtr only pays off if we are actually getting
that optimization. If we are passing a raw pointer, then using PassRefPtr
for the function argument type doesn’t help much. It just puts a ref at the
call site, a ref that otherwise would happen inside the function. It may
even cause a bit of code bloat if there is more than one call site.
>
> Conceptually speaking, PassRefPtr only pays off if the context is a clear
transfer of ownership. Passing an object that the recipient *might* later
choose to take shared ownership of is not enough. Clients are always welcome
to take shared ownership of something passed with a raw pointer.
>
> Because there are also costs to PassRefPtr, we should reserve PassRefPtr
arguments for cases where the optimization will really pay off and for where
the function definitely is taking ownership. Those functions do exist, but
many current uses of PassRefPtr for arguments do not qualify.
>
> 2:
>
> Recently, I’ve noticed that many bugs simply would cease to exist if we
used RefPtr more and raw pointer less for things like local variables and
data members.
>
> The time it’s safe to use a raw pointer for a local variable or data
member for a reference counted object pointer is when there is some
guarantee that someone else is holding a reference. It can be difficult to
have such a guarantee and those guarantees are fragile as code executes.
Nowhere is that more clear than in loader-related code.
>
> Some are loathe to use RefPtr for data members because they are concerned
about reference cycles. Generally speaking, we can eliminate the worry about
reference cycles by making destruction include a “closing” process, which
can null out all the references and break cycles. If we find it’s necessary
we can also look into an efficient WeakPtr implementation. Some have been
enthusiastic about this in the past. I have been a bit less so because I
don’t know of an efficient implementation strategy.
>
> Conclusion:
>
> A specific example where an argument has type PassRefPtr, but that does
not seem like the correct design, is the the node argument in the
constructors of the various HTMLCollection classes.
>
> Examples of where we are using raw pointers, but should use RefPtr instead
abound. Sadly there is no way to qualify a member function to make “this” a
RefPtr, so we are stuck with the “protector” idiom for the this pointer.
>
> Maybe we can even find a way to discuss these two issues in the RefPtr
document without making it too confusing.
>
> Comments are welcome. But lets not bikeshed <
http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality> this!
>
> -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110618/b8a10bef/attachment.html>