1266639 - Don't separately heap-allocate PLDHashTables within XPCMaps

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Nicholas Nethercote [inactive]]

I was looking at a crash report involving XPCMaps
(https://crash-stats.mozilla.com/report/index/10b7f3fb-224a-4862-b0e5-c802a2160421)
which made me ask "can ClassInfo2WrappedNativeProtoMap:mTable be null?" and I
realized it couldn't because that member is infallibly initialized in the
constructor and only deleted in the destructor.

Which means it doesn't need to be heap-allocated, it can just be an inline
member. And the same is true for all the PLDHashTables in the other XPCMaps.

Comment 1

[Nicholas Nethercote [inactive]]

Attachment: Don't separately heap-allocate PLDHashTables within XPCMaps

Most of the XPCMap classes contain a |PLDHashTable*|. This can be changed to a
|PLDHashTable|, which avoids some malloc/free calls, removes the needs for
explicit destructors, and removes "can this pointer be null?" questions.

The patch also cleans up the iterators provided by XPCMap classes a little.

Comment 2

[Nicholas Nethercote [inactive]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/048c047097a97068fa5e4f2592c53e59449ab8fd
Bug 1266639 - Don't separately heap-allocate PLDHashTables within XPCMaps. r=mrbkap.

Comment 3

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/048c047097a9