Today, danakj@ wrote a patch and couldn't figure out why an object bound into a SameThreadClosure wasn't getting freed: https://codereview.chromium.org/1830033003. Just glancing at this code, it's very mystifying to understand this would happen: there's no obvious way for Oilpan to trace into SameThreadClosure, so if anything, objects bound into SameThreadClosures should be getting GCed mistakenly freed, not mistakenly kept alive.
Eventually, esprehn@ noticed that we have special template traits that magically turn raw pointers to GarbageCollected objects into a Persistent handle: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/heap/Handle.h&l=1432
This is very magical and not at all obvious from the callsite. I propose that we make WTF::bind more like base::Bind() by doing two things:
1. Make WTF::bind on a raw pointer to a GCed object a compile-time error. This is just like how base::Bind(&F, my_refcounted_object) won't compile in Chromium: [1]
2. Add the Oilpan equivalents of base::Owned, base::RetainedRef, etc [2]. This way it will be obvious at the call site that it is a strong or weak binding. I guess that we'll want PersistRef and WeaklyPersistRef (names are a strawman, happy for better suggestions). I'm not sure if there are any other useful wrappers: I don't think we'd want an equivalent of Unretained() for GCed objects, but maybe there's some edge case where that would be useful.
Also, I guess this might be easier to do once non-Oilpan is removed, but I believe that's likely to happen very soon.
[1] https://code.google.com/p/chromium/codesearch#chromium/src/base/memory/raw_scoped_refptr_mismatch_checker.h&rcl=1458848021&l=27
[2] https://code.google.com/p/chromium/codesearch#chromium/src/base/bind_helpers.h&l=18
Comment 1 by dcheng@chromium.org
, Mar 25 2016