PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more

[Mike Hommey]

Hi,

In the next few weeks, there is going to be a reduction in the number of
our memory allocator wrappers/functions, for essentially the following
reasons:
- we have too many of them,
- developers rarely know which one to use, which results in:
- developers often make mistakes[1]

This started today with the landing of bug 1138293, which effectively
removed moz_malloc, moz_realloc, moz_calloc and moz_free.

They were replaced, respectively, with malloc, realloc, calloc and free,
because that works™.

If you have pending patches that use moz_malloc, moz_realloc,
moz_calloc, moz_free, you can just remove the moz_ prefix.

The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist,
and memory allocated with them can be freed with free.

With that being said, please refrain from using any of the functions
mentioned above. Please prefer the C++y new and delete. new is
infallible by default (equivalent to moz_xmalloc). If you need an
equivalent to moz_malloc, use fallible new instead:

new (fallible) Foo()

Please note that this shouldn't make uplifting harder. Platform patches
using malloc/free/new/delete should apply and work just fine on beta,
aurora and esr (with a few exceptions ; if you uplift something from
mfbt/mozglue that uses the memory allocator, please check with me).

Cheers,

Mike


1. if you look for it, you'll find cases of one family used for
allocation and another for deallocation, for possibly close to all
combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc,
new).

[Kyle Huey]

I assume that means that we have abandoned the plan to eventually make
malloc infallible?

- Kyle

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Mike Hommey]

On Tue, Mar 31, 2015 at 09:43:39AM -0700, Kyle Huey wrote:
> I assume that means that we have abandoned the plan to eventually make
> malloc infallible?

I think we should just use operator new more. We're writing C++ code
after all.

Mike

[Neil]

Mike Hommey wrote:

> 1.
>
>if you look for it, you'll find cases of one family used for allocation and another for deallocation, for possibly close to all combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc, new).
>
>

It used to be that you didn't have to look very hard. (At one point I
instrumented NS_Alloc(=nsMemory::Alloc), PR_Malloc, malloc and new, and
filed several bugs on the mismatches I found, which means that Gecko 2
wasn't too bad in this respect.)

--
Warning: May contain traces of nuts.

[Mike Hommey]

And now, nsMemory::Alloc, nsMemory::Free and nsMemory::Realloc are gone
as well.

Mike

> 1. if you look for it, you'll find cases of one family used for
> allocation and another for deallocation, for possibly close to all
> combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc,
> new).

[Alex Webster]

Please unsubscribe me

[Mike Hommey]

Today was NS_Alloc, NS_Realloc and NS_Free's turn.

Mike

[lame...@gmail.com]

On Tuesday, March 31, 2015 at 9:00:01 AM UTC+3, Mike Hommey wrote:
> Hi,
>
> In the next few weeks, there is going to be a reduction in the number of
> our memory allocator wrappers/functions, for essentially the following
> reasons:
> - we have too many of them,
> - developers rarely know which one to use, which results in:
> - developers often make mistakes[1]
>
> This started today with the landing of bug 1138293, which effectively
> removed moz_malloc, moz_realloc, moz_calloc and moz_free.
>
> They were replaced, respectively, with malloc, realloc, calloc and free,

> because that works(tm).

>
> If you have pending patches that use moz_malloc, moz_realloc,
> moz_calloc, moz_free, you can just remove the moz_ prefix.
>
> The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist,
> and memory allocated with them can be freed with free.
>
> With that being said, please refrain from using any of the functions
> mentioned above. Please prefer the C++y new and delete. new is
> infallible by default (equivalent to moz_xmalloc). If you need an
> equivalent to moz_malloc, use fallible new instead:
>
> new (fallible) Foo()
>
> Please note that this shouldn't make uplifting harder. Platform patches
> using malloc/free/new/delete should apply and work just fine on beta,
> aurora and esr (with a few exceptions ; if you uplift something from
> mfbt/mozglue that uses the memory allocator, please check with me).
>
> Cheers,
>
> Mike
>
>
> 1. if you look for it, you'll find cases of one family used for
> allocation and another for deallocation, for possibly close to all
> combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc,
> new).

Just pointing out that the removal of these methods might break proprietary code. Actually, it breaks "libqc_b2g_ril.so"

>Failed to load native module at path '/system/b2g/distribution/bundles/libqc_b2g_ril/libqc_b2g_ril.so': (80004005) dlopen failed: cannot locate symbol "moz_free" referenced by "libqc_b2g_ril.so"...