RFR: JDK-8322943: runtime/CompressedOops/CompressedClassPointers.java fails on AIX [v2]

[Goetz Lindenmaier]

On Wed, 6 Mar 2024 12:45:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi @tstuefe, this is a fix for an existing issue. Changing the behavior of the AIX allocation is not the intention of this fix.  Modernizing the AIX memory allocation is a possible follow-up. Also we need to backport this, so it should be fix-only. Thus I think we should really do the 4K/256M distiction here to match the allocation implemented in os_aix.cpp.
>
> Hi @GoeLin ,
> 
> not sure what you understood from my comment, but it was not what I was writing.
> 
>> Hi @tstuefe, this is a fix for an existing issue. Changing the behavior of the AIX allocation is not the intention of this fix. Modernizing the AIX memory allocation is a possible follow-up. 
> 
> Which I did not propose? Quoting myself here:
> 
> "Other than that, please slim the fix down to the necessary...
> The only really needed parts are the one in os::reserve_memory_inbetween. T**his is a small issue, let's keep the patch small and confined.**"
> 
>> Also we need to backport this, so it should be fix-only. 
> 
> Backport to where? `os::reserve_memory_inbetween` was introduced with https://bugs.openjdk.org/browse/JDK-8312018, which was introduced with JDK 22. The hunk affecting `virtualspace.cpp` has nothing to do with this problem, and should not be part of this patch.
> 
>> Thus I think we should really do the 4K/256M distiction here to match the allocation implemented in os_aix.cpp.
> 
> Which does not follow from "it should be a minimal fix". The 4K scenario is fictional. And even if it were not, aligning reservations to SHMLBA is never wrong, not even if you use mmap. So why the added complexity?
> 
> To be clear, I dislike it because of the the n times copy-pasted logic spread over the code base. If it were just one hunk in os.cpp, I would not care about the 4K page mode.

Hi @tstuefe, I read and understood all of your reply. I was referring to your "I don't think we need to cater to the 4K page mode." statement.  The 4K page mode is current state of the AIX implementation, and in my eyes the error is in virtualspace and os.cpp to use a  wrong alignement for the attach points, not in os_aix.cpp.  
Also, for the attach point randomization, it well makes a difference if you use 4K or 256M. There are less than 16 attach points aligned to 256M for a 1G allocation request within 4G, which makes  allocation in the lowest 4G fail (unscaled mode)
.
I was not aware the os.cpp problem appeared only after 21.

For the n-times copied logic: There are only two places in the JVM coding. The others are in tests. Obviously, the tests must be adapted to the JVM coding.
Joachim's original proposal was to encapsulate this in a new function. This moves the logic into the aix coding. You voted against this. So what to do now?

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

PR Comment: https://git.openjdk.org/jdk/pull/18105#issuecomment-1980869544