Improve the code cache allocation process on Linux #2095
Conversation
On the OMR side: add a new Virtual Memory Option called OMRPORT_VMEM_ADDRESS_HINT Change the method getMemoryInRangeForDefaultPages() to do the following: - when OMRPORT_VMEM_ADDRESS_HINT is used, instead of trying page by page to allocate in the desired region, we stop after the first attempt and return whatever default_pageSize_reserve_memory() gives us - when doing OMRPORT_VMEM_ALLOC_QUICK, do not try the slow search with mmap if the fast search with smaps failed - when doing OMRPORT_VMEM_ALLOC_QUICK, avoid doing the range check when OMRPORT_VMEM_ADDRESS_STRICT is not set On the OpenJ9 side: change the JIT to do the following during code cache allocation - try to allocate memory providing a desired address and setting OMRPORT_VMEM_ADDRESS_HINT - if the address returned by the OS is not within (2GB - 24MB) of the JIT dll, then try again by setting OMRPORT_VMEM_ALLOC_QUICK and a much larger address range(the full 2GB - 24MB from JIT dll address range), but not setting OMRPORT_VMEM_STRICT_ADDRESS and accept whatever we get back - refactor redundant code into functions and change the order of operation inside J9::CodeCacheManager::allocateCodeCacheSegment to make the code cleaner The OpenJ9 side change is dependent on the OMR side change, therefore pull in the OMR side change first. See issue 270 in OpenJ9 for more detail. Signed-off-by: Harry Yu <[email protected]>
|
@DanHeidinga Hi Dan, could you or someone on the vm team who's familiar with memory management in the portlib review this change please? This is part of the fix for openj9's issue270 (eclipse-openj9/openj9#270). The OMR side change needs to be merged before the OpenJ9 change goes in. Thanks a lot! |
|
@pdbain-ibm could you review these changes? |
include_core/omrport.h
Outdated
| * - If not set, search memory page by page until returned address is within desired range | ||
| * - If set, return whatever mmap gives us | ||
| * - this option is based on the observation that mmap would take the preferred address as a hint about where to place the mapping | ||
| * - therefore instead of trying page after page to allocate in the desired region, we stop after the first attempt and return whatever default_pageSize_reserver_memory() gives us as it might give us an address that's good enough |
There was a problem hiding this comment.
What if the address is NOT good enough? There are already STRICT flags so how does this change work if someone has also passed in STRICT?
There was a problem hiding this comment.
Also what happens for non-default page sizes? By default we the GC and other components request large pages when they are available.
There was a problem hiding this comment.
Thanks for taking your time to review this! If the address is not good enough, then one can try again with other options (i.e. with OMRPORT_VMEM_ALLOC_QUICK and larger range in this case). When HINT is set, we don't really care about the STRICT flag anymore. I guess if someone wants STRICT only then they shouldn't be using the HINT option. The whole idea of the hint was based on the observation that mmap would give us a memory address that's close enough even if it's not in the requested range. We don't think the HINT option works for large pages as it uses shmat instead of mmap. The behaviour for large pages stays the same. @mpirvu Hi Marius, correct me if I'm wrong.
There was a problem hiding this comment.
Harry's response is correct.
If both STRICT and HINT are specified, STRICT is ignored. The difference between HINT and non-STRICT is that with HINT there is only one allocation attempt while in the non-STRICT case there could be many attempts.
Large page allocations are non affected by HINT because the allocation is done with shmat which does not have the notion of a hint like mmap does.
There was a problem hiding this comment.
Can we make sure that it is documented that HINT has no effect on large page allocations?
|
genie-omr build all |
Document that OMRPORT_VMEM_ADDRESS_HINT has no effect on large page allocations. Signed-off-by: Harry Yu <[email protected]>
|
Only comment changes since the last CI builds |
On the OMR side: add a new Virtual Memory Option called OMRPORT_VMEM_ADDRESS_HINT
Change the method getMemoryInRangeForDefaultPages() to do the following:
On the OpenJ9 side: change the JIT to do the following during code cache allocation
The OpenJ9 side change is dependent on the OMR side change, therefore pull in the OMR side change first.
See issue 270 in OpenJ9 for more detail.
Signed-off-by: Harry Yu [email protected]