[m-rev.] for review: delete some redundant checks for NULL

[Julien Fischer]

On Sat, 3 May 2025 at 18:05, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> I asked boehm_gc's maintainer which allocating macros and functions
> are guaranteed never to return NULL unless the out-of-memory handler
> itself returns NULL, and they include all the ones we use. (I created a pull
> request to make this explicit in boehm_gc's upstream documentation
> of all the relevant macros/functions; that request was accepted.)
> So this diff deletes the NULL checks that we now know are redundant.
> For review by anyone.
>
> Since the deleted tests were extremely easy for branch predictors to handle,
> I don't expect a significant speedup. However, next I intend to look into
> optimizing away calls to MR_GC_malloc, MR_GC_malloc_atomic et al
> if we using boehm gc; since their bodies now contain nothing but
> a call to the associated boehm allocation macro, calls to them can be replaced
> by a direct invocation of that macro. This should yield a bigger speedup,
> though I don't know what it will do to code size.
>
> BTW, does anyone happen to know why *initializing* conservative gc
> handles both MR_BOEHM_GC and MR_HGC, but the alliocation functions
> themselves do not handle MR_HGC, and assume, incorrectly, that
> MR_CONSERVATIVE_GC can mean only MR_BOEHM_GC?

I wouldn't read much into it - HGC (as I am sure you are aware) is highly
incomplete.

> Avoid redundant NULL check on Boehm alloc results.
>
> runtime/mercury_memory.c:
>     In the functions that call GC_MALLOC, GC_MALLOC_ATOMIC,
>     GC_MALLOC_UNCOLLECTABLE or GC_REALLOC, do not check whether
>     the pointers they return are NULL, since the oom (out-of-memory)
>     handler we specify for Boehm gc will have already checked for NULL,
>     and it will abort the program instead of returning NULL.
>
> runtime/mercury_memory.h:
>     Make some comments more readable.
>
> runtime/mercury_wrapper.c:
>     Document mercury_memory.c's reliance on the oom handler.
>
>     Check for MR_BOEHM_GC explicitly, not via an inference.

That's fine.

Julien.