-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gencon tenure contraction amount is suboptimal #5627
Comments
Related changes:
For the second above, OMR PR 5543, the following testing was done:
For the third above, OMR PR 5635 for empty LOA contraction, the following testing was done:
More test results to come.. |
That 1 compaction to aid contraction was with 5543 but default minf/maxf? Without 5543 we would never see compaction to aid contraction ? |
See related: github.com/eclipse-openj9/openj9/issues/7005
It was observed that tenure contraction in gencon may be suboptimal. The original observations and code inspection noted two possible issues: (1) tenure cannot contract beyond the size of the LOA even when the LOA is empty, and (2) a possibly unnecessary heuristic prevents tenure from compacting to increase the available maximum contraction size when only 10% or greater of the requested contraction amount is available.
(1) A minimum LOA size of 0 allows tenure to contract beyond the LOA size when the LOA is empty and non-existent. However, a reduced LOA may reduce the available free space at the end, and therefore the available contraction size, when the LOA is not empty. Verbose GC logs provided in issue 7005, and those from various tests (specjbb2015 and jgrinders), show that the LOA is typically not empty. Allowing tenure to contract beyond the size of an empty LOA can only increase contraction when the LOA is empty but should have no disadvantage.
(2) Before doing a contraction, the amount of free space at the end of tenure is checked. If it is at least 10% of the requested contraction amount, no additional compaction is performed before contracting. This limits the frequency of compactions, but may also reduce the contraction amount by up to 90% if only 10% of the requested contraction size is available. Relaxing or removing this heuristic may increase the available maximum contraction size through extra compaction, but compacting more may effect performance.
Further investigation revealed a bug preventing evaluation of the heuristic (2) above. Unfortunately, fixing this bug risks losing performance by increasing compaction frequency. Consequently, a proposed fix is to add a new option to configure this heuristic amount. The possible performance impact has been tested using jgrinders and specjbb2015. Though this doesn't necessarily cover every case, even when adjusting settings to maximize contraction and relaxing the 10% heuristic, compaction to increase contraction seems limited.
The text was updated successfully, but these errors were encountered: