RFR: JDK-8327210: AIX: Delete obsolete parameter Use64KPagesThreshold
Joachim Kern
jkern at openjdk.org
Mon Mar 11 10:04:01 UTC 2024
On Mon, 11 Mar 2024 09:57:22 GMT, Joachim Kern <jkern at openjdk.org> wrote:
>>> Looks good. Do we need a CSR?
>>
>> Grey area. Normally yes, but since this is AIX only, the guys at over at SAP can probably decide on their own.
>>
>> We need, however, to follow the normal deprecation process.
>>
>> @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.
>
>> @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?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18171#issuecomment-1988029682
More information about the hotspot-runtime-dev
mailing list