RFR: JDK-8327210: AIX: Delete obsolete parameter Use64KPagesThreshold

[Thomas Stuefe]

On Mon, 11 Mar 2024 10:01:21 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>>> @JoKern65 Please don't just remove the option, deprecate it. See comments in arguments.cpp about deprecation. The purpose of this is to give customers a time window within which the option will still be accepted, albeit ignored.
>> 
>> It is a developer option. Who is the customer interested in it despite IBM and us?
>> And if I add a line in arguments.cpp, should it like 
>> `{ "Use64KPagesThreshold",     JDK_Version::jdk(22), JDK_Version::jdk(23), JDK_Version::jdk(25) },`
>> or which versions should I use instead?
>
>> @JoKern65 I am about 90% sure you could throw away more code. I think all that `vmembk_xxx` business was only there to ensure we remembered whether we used `mmap` or `shmat` when reserving a particular range and thus used the correct APIs when releasing that range. Since we now always either do mmap or shmat, we don't have the situation where we have different reservations done with different APIs. So we could remove that bookkeeping and simplify os::release and so forth.
>> 
>> Up to you if you do it. Can also be done in a separate RFE.
> 
> Hmm, I'm thinking about enabling 64K mmap() instead of shmget() if the OS is AIX 7.3 TL1 or higher. Then we still need the  `vmembk_xxx` or?

> > > @JoKern65 Please don't just remove the option, deprecate it. See comments in arguments.cpp about deprecation. The purpose of this is to give customers a time window within which the option will still be accepted, albeit ignored.
> > 
> > 
> > It is a developer option. Who is the customer interested in it despite IBM and us? And if I add a line in arguments.cpp, should it like `{ "Use64KPagesThreshold", JDK_Version::jdk(22), JDK_Version::jdk(23), JDK_Version::jdk(25) },` or which versions should I use instead?
> 
> Drive by comment, not a review.
> 
> Only "product" and "manageable" options require the full CSR + deprecation process. Experimental, diagnostic, develop, &etc options don't. They aren't considered to be part of the product API. https://wiki.openjdk.org/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process

Ah, sorry. I could have sworn we made these options product options. Great, no CSR required.

> > @JoKern65 I am about 90% sure you could throw away more code. I think all that `vmembk_xxx` business was only there to ensure we remembered whether we used `mmap` or `shmat` when reserving a particular range and thus used the correct APIs when releasing that range. Since we now always either do mmap or shmat, we don't have the situation where we have different reservations done with different APIs. So we could remove that bookkeeping and simplify os::release and so forth.
> > Up to you if you do it. Can also be done in a separate RFE.
> 
> Hmm, I'm thinking about enabling 64K mmap() instead of shmget() if the OS is AIX 7.3 TL1 or higher. Then we still need the `vmembk_xxx` or?

Yes, you are right. Okay, leave it in.

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

PR Comment: https://git.openjdk.org/jdk/pull/18171#issuecomment-1990986335
PR Comment: https://git.openjdk.org/jdk/pull/18171#issuecomment-1990987215