Skip to content
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

Open
jason-hall opened this issue Oct 22, 2020 · 2 comments
Open

Gencon tenure contraction amount is suboptimal #5627

jason-hall opened this issue Oct 22, 2020 · 2 comments
Labels

Comments

@jason-hall
Copy link
Contributor

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.

@jason-hall
Copy link
Contributor Author

Related changes:

For the second above, OMR PR 5543, the following testing was done:

  • I found that the options which caused the compact to aid contract path to execute the most were -Xmaxf0.1 -Xminf0.05.
  • In 9 runs of jgrinder tests (hours of run time), I observed an average of 62 contractions with reason "excess free space following gc". Of those, there was an average of only 1 compaction to aid contraction. With the 10% heuristic configured to 100% (it will compact to aid contraction any time the full contraction amount is not available), I observed an average of 5 of the ~60 contractions also did a compaction.
  • In a run of specjbb2015 with the above options, a compact to aid contraction was observed an average of 21 times out of 236 contracts. Without the fix, the same run averaged 2 compactions. While this is a large increase in the number of compactions, its still only 21 out of 236 contractions, in a 30 minute run artificially configured to contract more often.

For the third above, OMR PR 5635 for empty LOA contraction, the following testing was done:

  • The gc options -Xmaxf0.1 -Xminf0.05 were again found to force the most contractions for testing and used for these tests
  • In running specjbb2015, out of ~26,000 GC verbose gc log repotrs of the current LOA size, the LOA was 100% free in about 2500 of those, or about 10% of the time. In that time, tenure contracted about 450 times. With the default global minimum/maximum contraction amount, contraction amount is not significantly increased. With a global maximum contraction of 10%, tenure contracts significantly more when the LOA is empty.
  • When running the _sanity.functional.regular tests, verbose gc reports LOA is 100% free on ~187,000 reports of 385,000 (nearly 50%). In that time, about 3000 contractions occurred.

More test results to come..

@amicic
Copy link
Contributor

amicic commented Nov 12, 2020

Of those, there was an average of only 1 compaction to aid contraction.

That 1 compaction to aid contraction was with 5543 but default minf/maxf? Without 5543 we would never see compaction to aid contraction ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants