<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Aptos" size="3"><span style="font-size:12pt;">
<div style="margin-top:5pt;margin-bottom:5pt;">Hi everyone,</div>
<div style="margin-top:5pt;margin-bottom:5pt;">Thank you all for the valuable and detailed discussion around AHS and heap management for G1. I wanted to share some thoughts that align with Thomas’s comments and clarify the best path forward, especially given
the distinctions between AHS (Automatic Heap Sizing) and Google’s Adaptive Heap Sizing (AHS-Google). I’ve included simple diagrams to illustrate the technical flow and interactions of each approach.</div>
<div style="margin-top:5pt;margin-bottom:5pt;"><font size="4"><span style="font-size:13.5pt;"><b>1. Consolidating Around SoftMaxHeapSize for Dynamic, Adaptive Sizing</b></span></font></div>
<div style="margin-top:5pt;margin-bottom:5pt;">Thomas’s suggestion to prioritize SoftMaxHeapSize as the main dynamic driver aligns with my understanding of an effective AHS model. Using SoftMaxHeapSize in this way allows us to minimize the CPU overhead associated
with frequent uncommit/commit cycles, which would be a potential risk with a more rigid setting like ProposedHeapSize. Here’s a basic illustration of how Automatic Heap Sizing (AHS) with SoftMaxHeapSize would work dynamically:</div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | External Inputs |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |-----------------------------|</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Global Memory Pressure |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - GCTimeRatio policy |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Heap tunables via |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | commandline |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> v</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | Automatic Heap |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | Sizing (AHS) |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> v</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | SoftMaxHeapSize (Dynamic) |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Guides heap size |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Shrinks under pressure |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Uses target heuristics |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> v</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | JVM Heap Management |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Adjusts committed memory |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Controls expansions & |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | contractions smoothly |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div style="margin-top:5pt;margin-bottom:5pt;">By consolidating around SoftMaxHeapSize as the primary “target” flag, we create a more straightforward, adaptive, and consistent experience.</div>
<div style="margin-top:5pt;margin-bottom:5pt;"><font size="4"><span style="font-size:13.5pt;"><b>2. The AHS-Google Approach and Its Challenges</b></span></font></div>
<div style="margin-top:5pt;margin-bottom:5pt;">Google’s current Adaptive Heap Sizing (AHS-Google) approach uses ProposedHeapSize as a fixed committed size target. While this allows for setting a specific target for memory use, it introduces some challenges,
particularly with forced uncommit/commit cycles that might ignore dynamic inputs. Here’s how this approach typically functions:</div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | AHS-Google Logic |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |-----------------------------|</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Periodic GC with target |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Uses ProposedHeapSize as |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | "optimal" committed size |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> v</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | ProposedHeapSize (Fixed) |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Forced committed memory |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Overrides dynamic inputs |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Can cause frequent |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | uncommit/commit cycles |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> v</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | JVM Heap Management |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - Follows set memory level |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | - May ignore external |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> | pressure signals |</span></font></div>
<div><font face="Courier New" size="2"><span style="font-size:10pt;"> +-----------------------------+</span></font></div>
<div style="margin-top:5pt;margin-bottom:5pt;">A purely AHS-based approach would allow SoftMaxHeapSize to adjust dynamically in response to real-time signals without forcing committed memory levels. This avoids unnecessary CPU cycles and provides a more adaptive
response to environmental changes, such as fluctuating memory demands in containerized and cloud environments.</div>
<div style="margin-top:5pt;margin-bottom:5pt;"><font size="4"><span style="font-size:13.5pt;"><b>3. Key Differences Between AHS and AHS-Google</b></span></font></div>
<div style="margin-top:5pt;margin-bottom:5pt;">In my understanding:</div>
<ul style="margin:0;padding-left:36pt;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b>AHS (Automatic Heap Sizing)</b>: Focuses on finding a reasonable heap size based on external memory pressure and dynamically adjusts according to environmental inputs. This aligns with Thomas’s point that AHS
should allow for minimal user intervention and let dynamic factors guide heap behavior.</li><li style="margin-top:5pt;margin-bottom:5pt;"><b>AHS-Google</b>: Treats ProposedHeapSize as a fixed input, overriding dynamic adjustments. While this gives more explicit control, it limits adaptability and could introduce inefficiencies, as mentioned earlier.</li></ul>
<div style="margin-top:5pt;margin-bottom:5pt;"><font size="4"><span style="font-size:13.5pt;"><b>4. Moving Forward with a Balanced, Dynamic AHS for G1</b></span></font></div>
<div style="margin-top:5pt;margin-bottom:5pt;">Based on the discussion, I suggest we focus on developing an AHS model that leverages SoftMaxHeapSize as the adaptable target, allowing the JVM to adjust based on real-time memory pressures and CPU usage. Integrating
multiple inputs dynamically will create a robust model for managing “noisy neighbor” challenges—a very real need in today’s cloud and container scenarios and one that AHS is well-suited to manage, as highlighted in Erik’s recent JVMLS presentation.</div>
<div style="margin-top:5pt;margin-bottom:5pt;">Thank you all again for the insightful conversation and technical contributions. I believe these steps will help us build a technically sound and stable AHS for G1.</div>
<div style="margin-top:5pt;margin-bottom:5pt;">Please feel free to correct any misunderstandings or clarify any points where further alignment is needed.</div>
<div style="margin-top:5pt;margin-bottom:5pt;">Regards,</div>
<div style="margin-top:5pt;margin-bottom:5pt;">Monica</div>
<div> </div>
<table width="285" style="width:171.2pt;margin-left:3.15pt;">
<col width="31" style="width:18.75pt;">
<col width="0" style="width:0;">
<col width="239" style="width:143.9pt;">
<col width="14" style="width:8.55pt;">
<tr>
<td><a href="https://outlook.office.com/bookwithme/user/6dc2f1f46dfd446aa456d1c1245cecd6@microsoft.com?anonymous&ep=bwmEmailSignature"><img src="https://res-h3.public.cdn.office.net/assets/bookwithme/misc/CalendarPerson20px.png"></a></td>
<td></td>
<td><a href="https://outlook.office.com/bookwithme/user/6dc2f1f46dfd446aa456d1c1245cecd6@microsoft.com?anonymous&ep=bwmEmailSignature"><font color="#0078D4">Book time to meet with me</font></a></td>
<td>
<table width="0" style="width:0;margin-left:5.4pt;">
<col width="0" style="width:0;">
<tr>
<td></td>
</tr>
</table>
<div> </div>
</td>
</tr>
</table>
<div> </div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;"><b>From:</b> hotspot-gc-dev <hotspot-gc-dev-retn@openjdk.org> <b>On Behalf Of </b>Jonathan Joo<br>
<b>Sent:</b> Thursday, October 17, 2024 7:11 PM<br>
<b>To:</b> Thomas Schatzl <thomas.schatzl@oracle.com><br>
<b>Cc:</b> hotspot-gc-dev@openjdk.org<br>
<b>Subject:</b> Re: Further discussion on Adaptable Heap Sizing with G1</span></font></div>
<div> </div>
<div>Hi Thomas,</div>
<div> </div>
<div>The points you mentioned make sense to me! There are some nuances that I'd like to dig into further to make sure that we are aligned. I think to summarize - I'm not sure exactly how SoftMaxHeapSize is intended to work, whereas we have experimented with
ProposedHeapSize at Google already, so I want to bridge my gap in understanding there. </div>
<div> </div>
<div>I appreciate you offering to meet and discuss! As far as meeting time - I'm currently in US Pacific time, but flexible in terms of when we meet. (I am generally awake from 9am-1am PT, so I am good to meet any time in that time period -- please let me know
what time works best for you.) Tuesday and Thursday of the coming week I have the most availability, but if you have any other dates/times in mind, I can let you know whether that works for me.</div>
<div> </div>
<div>Best,</div>
<div> </div>
<div>~ Jonathan</div>
<div> </div>
<div>On Mon, Oct 14, 2024 at 2:52<font face="Arial"> </font>AM Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com"><font color="blue"><u>thomas.schatzl@oracle.com</u></font></a>> wrote:</div>
<div>Hi,<br>
<br>
On 11.10.24 09:16, Jonathan Joo wrote:<br>
> Hi Thomas,<br>
> <br>
> I think what this suggestion overlooks is that a SoftMaxHeapSize that<br>
> guides used heap size will automatically guide committed size: i.e. if<br>
> G1 shrinks the used heap, G1 will automatically shrink (and keep) the<br>
> committed size.<br>
> <br>
> So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.<br>
> <br>
> <br>
> If I'm understanding this correctly - both ProposedHeapSize and (the <br>
> proposed version of) SoftMaxHeapSize have similar semantics, but <br>
> actually modify the heap in different ways. SoftMaxHeapSize helps us <br>
> determine when to start a concurrent mark, whereas ProposedHeapSize <br>
> doesn't actually trigger any GC directly, but affects the size of the <br>
> heap after a GC. Is that correct? Would it make sense then to have both <br>
> flags, where one helps set a trigger point for a GC, and one helps us <br>
> determine the heap size we are targeting after the GC? I might also be <br>
> missing some nuances here.<br>
<br>
I think SoftMaxHeapSize (or actually either) will result in <br>
approximately the same behavior. The difference is in intrusiveness.<br>
<br>
ProposedHeapSize forcefully attempts to decrease the committed heap size <br>
and then the rest of the "heap sizing machinery" follows, while <br>
SoftMaxHeapSize gives a target for the "heap sizing machinery" and <br>
committed heap size follows.<br>
<br>
ProposedHeapSize has the following disadvantages (as implemented):<br>
<br>
- since it forces committed heap size, I expect that in case you are <br>
close or above that target, you can get frequent uncommits/attempts to <br>
uncommit which waste cpu cycles.<br>
<br>
Hopefully, by giving the heap sizing machinery a goal, it will itself <br>
determine a sustainable committed memory level without too frequent <br>
commits and uncommits.<br>
<br>
- for some reason it does not allow less memory to be committed than <br>
proposed (but still larger than MinHeapSize). This can be inefficient <br>
wrt to memory usage.<br>
I.e. it basically disables other heap sizing afaict.<br>
<br>
- (that's more a nit) the use of "0" as special marker for <br>
SoftMaxHeapSize is unexpected.<br>
<br>
This mechanism kind of feels like a very blunt tool to get the desired <br>
effect (a certain committed heap) without caring about other goals. It <br>
may be necessary to pull out the immediately un/commit hammer in some <br>
situations, and imho, let's not give that hammer to users as the first <br>
option to screw themselves.<br>
<br>
> <br>
> I.e. if I understand this correctly: allowing a higher GC overhead,<br>
> automatically shrinks the heap.<br>
> <br>
> <br>
> Exactly - in practice, tuning this one parameter up (the target gc cpu <br>
> overhead) correlates with decreasing both the average as well as maximum <br>
> heap usage for a java program.<br>
> <br>
> I noticed the same with the patch attached to the SoftMaxHeapSize CR<br>
> (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8236073&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506605286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tDXYfCNOqe7cR%2FnHwmD%2F87tbeUvo06K6mpTVqKjaYmw%3D&reserved=0"><font color="blue"><u>https://bugs.openjdk.org/browse/JDK-8236073</u></font></a><br>
> <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8236073&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506634149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CE1feUMnxtgoxREf%2BaLK9yyv6a545238mDXDLUMcwF4%3D&reserved=0"><font color="blue"><u>https://bugs.openjdk.org/browse/JDK-8236073</u></font></a>>)
discounting effects of<br>
> Min/MaxHeapFreeRatio (i.e. if you remove it,<br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8238686&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506653746%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mwYKt9FtJ72rRZYNgtXHRwHBCGRzgIGeeJj56WsQwvs%3D&reserved=0"><font color="blue"><u>https://bugs.openjdk.org/browse/JDK-8238686</u></font></a><br>
> <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8238686&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506670981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qm7IT0%2BgGk%2FC6rEufD0KodFoKtLND40Hu72tyMXW28A%3D&reserved=0"><font color="blue"><u>https://bugs.openjdk.org/browse/JDK-8238686</u></font></a>> explains
the issue).<br>
> In practice, these two flags prohibit G1 from adjusting the heap unless<br>
> the SoftMaxHeapSize change is very large.<br>
> <br>
> <br>
> So I would prefer to only think of an alternative to SoftMaxHeapSize if<br>
> it has been shown that it does not work.<br>
> <br>
> <br>
> Given that you have a much stronger mental model than I do of how all <br>
> these flags fit together in the context of G1 GC, perhaps it would be <br>
> helpful to schedule some time to chat in person! I think that would help <br>
> clarify things much more quickly than email. To be clear - I have no <br>
> reason to doubt that SoftMaxHeapSize does not work. On the other hand, <br>
> could we possibly make use of both flags? For example, could <br>
> SoftMaxHeapSize potentially be a good replacement for our periodic GC?<br>
<br>
Not sure what periodic GC has to do with SoftMaxHeapSize.<br>
<br>
> <br>
> There is the nit that unlike in this implementation of ProposedHeapSize,<br>
> SoftMaxHeapSize will not cause uncommit below MinHeapSize. This is<br>
> another discussion on what to do about this issue - in a comment in<br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8236073&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506688389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=U3SJVBO%2F0gtF4xZOLdGi2QMORV8DIht1FciPivWgMA8%3D&reserved=0"><font color="blue"><u>https://bugs.openjdk.org/browse/JDK-8236073</u></font></a><br>
> <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8236073&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506706310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CMgyTApGCNiM6WoIWf%2F1T9GCXRIpgvaTQ08QJGhSajw%3D&reserved=0"><font color="blue"><u>https://bugs.openjdk.org/browse/JDK-8236073</u></font></a>> it
is proposed to make<br>
> MinHeapSize manageable. <br>
> <br>
> <br>
> How useful is MinHeapSize in practice? Do we need it, or can we just set <br>
> it to zero to avoid having to deal with it at all?<br>
<br>
I think you are mixing AHS (give decent heap sizing in presence of <br>
external memory pressure) and getting "optimal" heap sizing (or iow <br>
"steering heap size" externally).<br>
<br>
AHS is mostly about the user not doing/setting any heap sizes; in this <br>
case just having min heap size very low is just fine just as suggested <br>
in the JEP.<br>
<br>
SoftMaxHeapSize (and ProposedHeapSize) is about the user setting a <br>
particular goal according to his whims. It is still interesting to set <br>
-Xms==-Xmx for e.g. fast startup or during heavy activity; however if an <br>
external system decides that it is useful to intermittently save memory <br>
up to a certain level, then follow that guidance.<br>
<br>
The mechanism to internally follow that guidance can be used by AHS.<br>
<br>
<br>
> <br>
> I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are<br>
> somewhat orthogonal.<br>
> <br>
> AHS (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F8329758&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506722980%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Aymh70Ju5C%2FX4hmtj2ri7EX4v%2F7NCA733kDBxAp%2FX8I%3D&reserved=0"><font color="blue"><u>https://openjdk.org/jeps/8329758</u></font></a><br>
> <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F8329758&data=05%7C02%7Cmonica.beckwith%40microsoft.com%7Cfdcf0de799d34a28c1a708dcef098c5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638648071506741674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=quHGouKrnBKMDAHLTmnKVOGZ8%2FCDY0z79FiRL5xN%2BSg%3D&reserved=0"><font color="blue"><u>https://openjdk.org/jeps/8329758</u></font></a>>)
is about finding a reasonable<br>
> heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize<br>
> are manual external tunings.<br>
> <br>
> <br>
> Wdyt?<br>
> <br>
> <br>
> I agree with the general idea - for us, we used a manual external flag <br>
> like ProposedHeapSize because we did not implement any of the AHS logic <br>
> in the JVM. (We had a separate AHS thread reading in container <br>
> information and then doing the calculations, then setting <br>
> ProposedHeapSize as a manageable flag.) The way I see it is that <br>
> SoftMax/ProposedHeapSize is the "output" of AHS, and then <br>
> SoftMax/ProposedHeapSize is the "input" for the JVM, after which the JVM <br>
> uses this input to adjust its behavior accordingly. Does that align with <br>
> how you see things?<br>
<br>
As mentioned in the other thread, SoftMaxHeapSize can be used by AHS to <br>
get heap to a certain level (based on memory pressure), but there is <br>
also that external entity that can modify SoftMaxHeapSize to adjust VM <br>
behavior.<br>
<br>
So ultimately there will be multiple inputs for target heap size (and <br>
probably I'm forgetting one or the other):<br>
<br>
* External memory pressure (AHS) (*)<br>
<br>
* CurrentMaxHeapSize<br>
<br>
* SoftMaxHeapSize<br>
<br>
* CPU usage (existing GCTimeRatio based policy)<br>
<br>
* other *HeapSize flags<br>
<br>
that need to be merged into some target heap level using some policy.<br>
<br>
After knowing that level, the VM needs to decide on a proper reaction, <br>
which might be anything from just setting internal IHOP goal, to <br>
(un-)committing memory directly, to doing the appropriate garbage <br>
collection in a "timely" fashion (which is where the regular periodic <br>
gc/marking comes in) or anything inbetween.<br>
<br>
(*) I am aware that the AHS JEP not only includes reaction on external <br>
memory pressure but also the merging of goals for different sources; <br>
some of them are ZGC specific. Some of them are already implemented in <br>
G1. So for this discussion it is imo useful to limit "AHS" in G1 context <br>
to things that G1 does not do. Ie. "return another goal based on <br>
external memory pressure", "min/max heap size defaults(!)", and "adjust <br>
adaptive sizing".<br>
<br>
> If we do indeed implement AHS logic fully within the JVM, then we could <br>
> internally manage the sizing of the heap without exposing a manageable <br>
> flag. That being said, it seems to me that exposing this as a manageable <br>
> flag brings the additional benefit that one could plug in their own AHS <br>
> implementation that calculates target heap sizes with whatever data they <br>
> want (and then passes it into the JVM via the manageable flag).<br>
> <br>
> Again, I wonder if meeting to discuss would be efficient, and then we <br>
> can update the mailing list with the results of our discussion. Let me <br>
> know your thoughts!<br>
<br>
It's fine with me to meet to recap and discuss above; please suggest <br>
some time.<br>
<br>
Hth,<br>
Thomas</div>
<div> </div>
</span></font>
</body>
</html>