RFR: 8263185: Mallinfo deprecated in glibc 2.33 [v4]

[Thomas Stuefe]

On Wed, 17 Mar 2021 09:33:02 GMT, Christoph Göttschkes <cgo at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 2238:
>> 
>>> 2236:   bool called_mallinfo = false;
>>> 2237:   bool might_have_wrapped = false;
>>> 2238: #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 33)
>> 
>> This is not needed - you are using a build-time value to determine whether to perform a runtime action. The mallinfo2 call should be attempted on all platforms regardless of the build platform characteristic.
>
> But we need to know the structure of the return type, which needs to be known at compile time because it is allocated on the stack. The only way I see to make this not compile time dependent would be to copy the structure from the system header to the HotSpot sources and always assume that every platform, which provides a mallinfo2 function, has the same prototype. I would like to avoid copying the struct definition from the system header to the HotSpot sources. Or am I missing something?

Which I suggested before. We do this in other places; in fact, every runtime-resolution of a system API via `dlopen` locally hard-codes the prototype of this function - in the form of the function pointer typedef. If that's accepted practice, why are we shy suddenly about making assumptions of how the return structure looks like?

We are not talking about a volatile function but an official glibc interface. mallinfo() did not change in 40 years. I'd expect mallinfo2() to be very stable.

Its not stack allocated. Its pointer is. All we really need to know is offset and size, within this structure, of that one member we access. For that, even copying that whole structure seems overkill IMHO.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2964