The name "aListener" is not very descriptive, and with the previous patch, it is only
used to pass in a manually-specified listener that was passed in to CycleCollectNow,
so rename things.
The hg diff for this commit is terrible, but all it is doing is taking the code
in nsCycleCollector::Collect from after PrepareForCollection through BeginCollection
and moving it into BeginCollection.
Move the two places we check global flags to decide if we want to use a listener, even if we
aren't passed in one. A later patch renames aListener to aForcedListener to make it less
confusing.
There's no reason to wait until CollectWhite to record what is garbage, and with incremental CC
we'll get more accurate logging by logging right away, rather than waiting until later when an
object may have gone away for some other reason.
Contrary to the comment here, I'm pretty sure this needs to be measured. mWeakMaps
is an array of little structs. Of course, in practice I doubt this amounts to anything.
This looks like a dubious optimization to skip most of a CC when the graph
is empty, dating from the dawn of the CC, but I doubt it is ever triggered
nowadays.
I looked through the NSPR socket creation functions that InitWithAddress
uses to see which errors they could return, and placed appropriate comments
in ErrorAccordingToNSPR.
The test coverage is not great; in particular, I wasn't able to find a way
to elicit "address in use" errors from Windows (although I could from
Linux); the web says that Windows is much more relaxed about binding
listening sockets than Unix derivatives. I'm interested in suggestions.
I broke out this this change on its own, because it seemed to require some care:
PR_ADDRESS_NOT_SUPPORTED_ERROR used to be lumped in with several other NSPR
error codes and reported as NS_ERROR_CONNECTION_REFUSED; and a dumb grep shows
that the NS_ERROR_ is widely checked for. Introducing the distinction might
require the new NS_ERROR_SOCKET_ADDRESS_NOT_SUPPORTED value to be checked for
everywhere that currently checks for NS_ERROR_CONNECTION_REFUSED.
But that seems unlikely to be necessary: first of all, it shouldn't really
be possible, via the XPCOM interface, to force this error path to occur at
present: the components' implementations are in complete control over which
socket address types get used. I also did a Try push with a call to
NS_ABORT if a PR_ADDRESS_NOT_SUPPORTED_ERROR ever flows through
ErrorAccordingToNSPR; there were no crashes.
But if that's so, then why introduce the new error code at all? A later
patch adds support for Unix-domain sockets, a type of socket address which
is *not* supported on non-Unix systems. In that case, a distinct error code
will help people diagnose problems quickly.
