968031 - Remove threadsafe refcounting from ContentParent

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

This has been unnecessary since bug 876989.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

This adds ContentParent to the CC graph but doesn't actually traverse or unlink anything.  The ContentParent memory reporter AddRef/Releases every ContentParent which ensures that these show up in logs from get_about_memory.py.

Comment 2

[Andrew McCreight [:mccr8]]

Comment on attachment 8393641 [details] [diff] [review]
Patch

Review of attachment 8393641 [details] [diff] [review]:
-----------------------------------------------------------------

CC stuff looks good to me, modulo the explanatory comments below.

::: dom/ipc/ContentParent.cpp
@@ +1953,4 @@
>  #endif
>  }
>  
> +NS_IMPL_CYCLE_COLLECTION_0(ContentParent)

Please add a comment explaining that you are doing this to ensure that ContentParent shows up in CC logs.  This will let future readers of this code understand why you are doing this weird thing without doing version control archaeology.

::: xpcom/glue/nsCycleCollectionParticipant.h
@@ +713,4 @@
>  #define NS_IMPL_CYCLE_COLLECTION_CLASS(_class) \
>   _class::NS_CYCLE_COLLECTION_INNERCLASS _class::NS_CYCLE_COLLECTION_INNERNAME;
>  
> +#define NS_IMPL_CYCLE_COLLECTION_0(_class)                                     \

Please add back in a variant of the deleted comment mentioning that most of the time you don't actually want to make something that would use the _0 macro a cycle collected class.  IIRC, this macro used to exist, and people used it for no good reason.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c35101b1c6fd

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c35101b1c6fd