JDK-8315524 : [aix] Reactivate and check os::attempt_reserve_between gtests
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: aix
  • Submitted: 2023-09-01
  • Updated: 2024-03-26
  • Resolved: 2024-03-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 23
23Resolved
Related Reports
Duplicate :  
JDK-8322943 - runtime/CompressedOops/CompressedClassPointers.java fails on AIX
Relates :  
JDK-8315321 - [aix] os::attempt_reserve_memory_at must map at the requested address or fail
Relates :  
JDK-8312018 - Improve reservation of class space and CDS
Description
In JDK-8312018 we excluded AIX from gtest execution of the new regression tests because of JDK-8315321. 

https://github.com/openjdk/jdk/blob/89d18ea40f3508f4053824fd47f0b0f85fe1d7c2/test/hotspot/gtest/runtime/test_os_reserve_between.cpp#L38-L40

Now the latter is fixed, re-examine and possibly enable those tests for AIX.
Comments
The change for JDK-8322943 reactivates os::attempt_reserve_between gtests on AIX.
26-03-2024
As https://bugs.openjdk.org/browse/JDK-8322943 suffers from the same problem and will provide a more generic solution, that solution is going to be used once available. Assigning to Joachim accordingly.
22-01-2024
The test can be activated w/o any error for AIX. However, the current setup does not make much sense if we deal with 64K pages, which I will try to explain: Running with 64K pages, AIX uses shmat(). Reservation with an exact target address (SHM_RND not set) is only possible if this address is aligned to SHMLBA (0x10000000). Otherwise, shmat() returns -1 with an errno of EINVAL. In the test, local class SpaceWithHole is employed to allocate space with a given region in the middle that is not allocated. This is mostly done in loops that shift the boundaries of the memory 'hole' by multiples of os::vm_allocation_granularity() with a maximum of 32 iterations. By that the highest address to start allocation for the higher region of the two intervals is below the SHMLBA aligned address, which makes every attempt to create SpaceWithHole fail - the test is skipped. My suggestion is to utilize SHMLBA as granularity within the test like indicated in this code snippet: test/hotspot/gtest/runtime/test_os_reserve_between.cpp: … struct ARMB_constants { static constexpr unsigned max_attempts = 32; static constexpr unsigned min_random_value_range = 16; static constexpr unsigned total_shuffle_threshold = 1024; + static constexpr size_t allocation_granularity = 268435456; // AIX: SHMLBA }; … - const size_t ag = os::vm_allocation_granularity(); + //const size_t ag = os::vm_allocation_granularity(); + const size_t ag = ARMB_constants::allocation_granularity; -> do this at all places where ag is defined for a subsequent instantiation of SpaceWithHole With according changes I was able to run the test OK while avoiding the previously observed skips. [~stuefe]: Thomas, could we clarify the role and intention of os:vm_allocation_granularity() here? Seems like it is more or less used as a synonym for page_size - I would not dare to change it to SHMLBA, which was my first naive thought. Thanks and regards Thomas
27-11-2023