On Fri, 29 Mar 2024 07:56:10 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 50:
>>
>>> 48: #undef malloc
>>> 49: extern void *malloc(size_t) asm("vec_malloc");
>>> 50: #endif
>>
>> This `#if` is not needed if we are building on AIX 7.2 TL5 SP7 or higher.
>> This is the case in our build environment, but I think IBM is still building
>> with SP5, which would run into build errors if I remove this `#if` now.
>
> While looking at this, I noticed that my question in
> https://github.com/openjdk/jdk/pull/14146#discussion_r1207078176 and
> followups had never been answered. Do you know the answers now?
>
> Quoting myself:
>
>> So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc?
>> What about free?
>> Removing that define and hard-coding it here assumes ... pointers it returns
>> work with the unchanged free() and realloc() the system provides, and will
>> always do so.
>> I am basically worried that undefining malloc, even if it seems harmless
>> now, exposes us to difficult-to-investigate problems down the road, since it
>> depends on how the libc devs will reform those macros in the future.
Other than that, and kind of depending on your answer: How important is it that
we catch every use of the original malloc? Can be safely mix the original
malloc with vec_malloc if logging is not involved?
I am asking, because from that it depends whether this hunk needs to appear
right behind `#include <stdlib.h>` or whether we can move it into the middle of
the file together with the other AIX stuff.
Because, if we move it into the middle of the file, we may miss any uses of
malloc that may happen in system headers (would be unusual for that to happen
but with IBM one never knows).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1544201412
