153214 - Kill internal use of nsIMemory?

Status: VERIFIED DUPLICATE of bug 153215

(Core :: XPCOM, defect)

Description

[Doug Turner (:dougt)]

Waterson cornered and drilled me yesterday for the need of nsIMemory.  The
arguments I gave were pathetic.  I spoke with rpotts today (the one who i knew
could argue for a nsIMemory better than I could), and he had better arguments,
yet they will were unrealistic.  

A couple points which came up:

1. To ensure that the same allocate is used.
  - by providing an interface to the allocate we use (malloc) should be enough.
 We don't have to use the interface directly.

2. We could do arena based allocation under the hood of nsIMemory in which at
shutdown of Gecko, we could dispose of the arena thereby freeing any memory leaks.
  - we already malloc/new directly.  
  - staying viglate on memory leaks is the only way to go.

3.  Easy to change allocator
  - nope.  just replace malloc at build time.

4. The one use case that we found was the following:  If someone were to embed a
prebuilt Gecko into their application and their application used SmartHeap,
there would be allocation and deallocation mismatches.  However, the solution to
this is have the embeder to use the nsIMemory interface.


So, what I think that I am proposing is the following:

a. In all mozilla code, we use malloc/free.  This means everywhere regardless of
crossing interface boundaries.
  
b. In the standalone xpcom glue code, we go through the nsIMemory to allocate. 
This is so that if the embedding can enforce the old "use nsIMemory" rule.  This
will be driven by a compiler flag.  (the standalone glue is built by the
embedder/component developer)

Thoughts?

Comment 1

[Sander]

*** This bug has been marked as a duplicate of 153215 ***

Comment 2

[Stephen Walker]

vrfy dup