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

[Christoph Göttschkes]

On Wed, 17 Mar 2021 14:57:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I don't know how glibc handles this, but the release notes of 2.33 states:
>> 
>>> The deprecated <sys/vtimes.h> header and the function vtimes have been removed.
>> 
>> So it looks like they are removing deprecated functions. I guess this doesn't mean that the symbol is no longer in the runtime library (because of symbol versioning, it should remain there), but the function declaration in the header has been removed.
>> 
>> I can confirm, that on a recent Arch Linux (which already has glibc 2.33) this header is no longer to be found in /usr/include. In the libc.so file, however, the symbol is still there:
>> 
>> $ readelf --dyn-sym -W /usr/lib/libc.so.6 |grep vtimes
>>    673: 00000000000f5c40    56 FUNC    GLOBAL DEFAULT   16 vtimes at GLIBC_2.2.5
>
>> I don't know how glibc handles this, but the release notes of 2.33 states:
>> 
>> > The deprecated <sys/vtimes.h> header and the function vtimes have been removed.
>> 
>> So it looks like they are removing deprecated functions. I guess this doesn't mean that the symbol is no longer in the runtime library (because of symbol versioning, it should remain there), but the function declaration in the header has been removed.
>> 
>> I can confirm, that on a recent Arch Linux (which already has glibc 2.33) this header is no longer to be found in /usr/include. In the libc.so file, however, the symbol is still there:
>> 
>> ```
>> $ readelf --dyn-sym -W /usr/lib/libc.so.6 |grep vtimes
>>    673: 00000000000f5c40    56 FUNC    GLOBAL DEFAULT   16 vtimes at GLIBC_2.2.5
>> ```
> 
> You are right :( Okay, then resolving mallinfo manually may be the best option.

I agree, that for compatibility reasons, we need to copy the struct definition to the VM sources. I did that and guarded the usage with `#ifdef __GLIBC__`. I copied the whole struct definition for both structs, to be forward and backward compatible, into the sources and adjusted the usage accordingly. I also made the declaration of the function pointers similar to others declared in os_linux.hpp.

@tstuefe: I don't know what you mean by:

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

The return type of `mallinfo` is not a pointer, it is the struct. Did you miss that, or do I missinterpret what you wrote?

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

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