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

[Christoph Göttschkes]

On Fri, 12 Mar 2021 14:54:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Chris,
>> 
>> are you sure this is true? That we are unable to run on machines with older glibcs than the build machine uses? This is new to me. 
>> 
>> If this is not true, I would dynamically resolve mallinfo2. This is too unimportant a functionality to introduce a hard glibc dependency.
>> 
>> Minor remarks inline.
>> 
>> ..Thomas
>
> Also please make sure you test on both new and old glibc and run some manual sanity tests. E.g. by connecting to a running VM via jcmd and executing VM.info. The output should appear somewhere in there, and match your expectations. The sign extension issue should have appeared when running on an older glibc with 50% probability as an unseemingly high value.
> 
> ---
> (Just remembered that when doing this originally I added some large malloc to explicitly test display for the range 2G < x < 4G and x > 4G.)

Thanks for your review, Thomas.

> are you sure this is true? That we are unable to run on machines with older glibcs than the build machine uses? This is new to me.

That's how I understand and experience symbol versioning. But I don't know if there should be support for Linux using glibc without symbol versioning. Also, I don't know in detail when the glibc bumps a symbol version, so it might be better to not rely on it here. I changed the implementation to use `dlsym` to resolve the symbols without any specific version.

I am resolving both functions, `mallinfo2` and `mallinfo`, because I am using `mallinfo` as a fallback function if we compiled against glibc >= 2.33. If `mallinfo` is not resolved using `dlsym`, there will be a compile time warning because of its deprecation. This compile time warning was the reason I opened up the bug report.

I fixed the regression I introduced and double checked that the overflow is handled as before. As you mentioned, the VM doesn't allocate enough under normal circumstances, so I didn't notice this during testing. I added additional allocations as suggested and tested again. Works as before now. I tested:

* build glibc 2.31 - runtime glibc 2.31
* build glibc 2.33 - runtime glibc 2.33
* build glibc 2.31 - runtime glibc 2.33

Output is as before, only that the VM built with 2.33 doesn't have the overflow problem anymore.

I also executed tier1 on both systems.

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

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