RFR: Initial sizing refactor [v2]
Y. Srinivas Ramakrishna
ysr at openjdk.org
Wed Dec 21 22:20:20 UTC 2022
On Wed, 21 Dec 2022 19:14:14 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> Maybe the target max-size for old-gen is auto-tuned to, e.g., 10% larger than the maximum old-gen live memory following old-gen concurrent mark with some bias given to more recently observed measurements of old-gen live-memory.
>
> I agree we can wire up more signals to the resizing mechanism. In the scenario you describe, where old generation has become _too small_ and old collections are running _too frequently_, the MMU based resizing would enlarge the old generation.
What do you do before any data is available for one of the MMU trackers? (for example before the first old collection cycle has happened.) I'd assume that the control algorithm wouldn't kick in until the data driving the control signal was valid and available. Where is that done?
-------------
PR: https://git.openjdk.org/shenandoah/pull/185
More information about the shenandoah-dev
mailing list