Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.28k
stars
721
forks
source link
Investigate codecache memory allocation and fix it #20440
i suspected currently semeru codecache is always allocated through malloc, because i saw the address is not in the expected region on aix even though i used option -Xlp:codecache:pagesize=64k. i.e. when non-default pagesize is requested, codecache should be allocated through shmget (the only programmable way to ask for non-default pagesize). then, it is expected to fall in 0x0a region and starting in a new segment (256MB). but i didn't see that. this might be true to other platforms as well.
this also is related to another build issue, namely executable's exempt status re SED (Stack Execution Disable) mechanism on AIX. When SED is enforced, writable malloc memory doesn't have executable permission. mmap-ed or shmget writable memory does.
i suspected currently semeru codecache is always allocated through malloc, because i saw the address is not in the expected region on aix even though i used option -Xlp:codecache:pagesize=64k. i.e. when non-default pagesize is requested, codecache should be allocated through shmget (the only programmable way to ask for non-default pagesize). then, it is expected to fall in 0x0a region and starting in a new segment (256MB). but i didn't see that. this might be true to other platforms as well.
this also is related to another build issue, namely executable's exempt status re SED (Stack Execution Disable) mechanism on AIX. When SED is enforced, writable malloc memory doesn't have executable permission. mmap-ed or shmget writable memory does.