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

[David Holmes]

On Wed, 17 Mar 2021 10:29:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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.

Sorry I missed the static use of the mallinfo2 struct.

If we want to be able to build and run in any combination then we need to workaround the struct definition.

With the current code if you build on an old system and run on a new one you will still use the old mallinfo. That probably isn't terrible, but assumes our minimal supported build systems will have mallinfo2 long before mallinfo is physically removed.

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

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