1711100 - Remove XPCOM leak logging from nsTArray_base

Status: RESOLVED FIXED

(Core :: XPCOM, task)

Description

[Nika Layzell [:nika] (ni? for response)]

This is for a few reasons:

• The leak logging isn't as useful as other types of logging, as
  nsTArray_base is frequently relocated without invoking a constructor,
  such as when stored within another nsTArray. This means that
  XPCOM_MEM_LOG_CLASSES cannot be used to identify specific leaks of
  nsTArray objects.

• The nsTArray type is layout compatible with the ThinVec crate with the
  correct flags, and ThinVec does not currently perform leak logging.
  This means that if a large number of arrays are transferred between rust
  and C++ code using ThinVec, for example within another ThinVec, they
  will not be logged correctly and might appear as e.g. negative leaks.

• Leaks which have been found thanks to the leak logging added by this
  type have often not been significant, and/or have needed to be
  circumvented using some other mechanism. Most leaks found with this type
  in them also include other types which will continue to be tracked.

Comment 1

[Andrew McCreight [:mccr8]]

If people are leaking nsTArrays of plain data that isn't tracked by leak checking, that should still show up in LSan, as a last resort.

Comment 2

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1711100 - Remove XPCOM leak logging from nsTArray_base,

This is for a few reasons:

• The leak logging isn't as useful as other types of logging, as
  nsTArray_base is frequently relocated without invoking a constructor,
  such as when stored within another nsTArray. This means that
  XPCOM_MEM_LOG_CLASSES cannot be used to identify specific leaks of
  nsTArray objects.

• The nsTArray type is layout compatible with the ThinVec crate with the
  correct flags, and ThinVec does not currently perform leak logging.
  This means that if a large number of arrays are transferred between rust
  and C++ code using ThinVec, for example within another ThinVec, they
  will not be logged correctly and might appear as e.g. negative leaks.

• Leaks which have been found thanks to the leak logging added by this
  type have often not been significant, and/or have needed to be
  circumvented using some other mechanism. Most leaks found with this type
  in them also include other types which will continue to be tracked.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9128360a5bf5
Remove XPCOM leak logging from nsTArray_base, r=mccr8

Comment 4

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9128360a5bf5