<div dir="ltr">Dear Thomas,<div><br></div><div>just to add on what Ruslan already said.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Depending on the patches' size it's probably best if you give me a<br>
webrev when your names show up there and I can make them publicly<br>
available.<br></blockquote></span><div>My colleague Rodrigo Bruno will take care of it.  </div><span><div></div></span></div></div></div></blockquote><div><br></div><div>I am preparing the webrev. My OCA should be ready in the next days. Whenever it is out, I will send the webrev.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_4622064130021278248h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> -Xmx Dynamic Limit Update <br>
> <br>
> To dynamically limit how large the committed memory (i.e. the heap<br>
> size) can grow, a new dynamically user-defined variable was<br>
> introduced: CurrentMaxHeapSize. This variable (defined in bytes)<br>
> limits how large the heap can be expanded. It can be set at launch<br>
> time and changed at runtime. Regardless of when it is defined, it<br>
> must always have a value equal or below to MaxHeapSize (Xmx - the<br>
> launch time option that limits how large the heap can grow). Unlike<br>
> MaxHeapSize, CurrentMaxHeapSize, can be dynamically changed at<br>
> runtime.<br>
> <br>
> For example dynamically set 1GB as the new Xmx limit<br>
> <br>
> jinfo -flag CurrentMaxHeapSize=1g <java_pid><br>
> <br>
> Setting CurrentMaxHeapSize at runtime will trigger a full collection<br>
> if the desired value is below the current heap size. After finishing<br>
> the full collection, a second test is done to verify if the desired<br>
> value is still above the heap size (note that a full collection will<br>
> try to shrink the heap as much as possible). If the value is still<br>
> below the current heap size, then an error is reported to the user.<br>
> Otherwise, the operation is successful. <br>
<br>
One alternative here could be to use a marking cycle + mixed gcs to<br>
reach that new CurrentMaxHeapSize again, which is again is a bit more<br>
complicated to achieve. I can help you implementing that if interested.<br>
<br>
In some cases you might even get away with just uncommitting empty<br>
regions and doing nothing else in response to this command.<br>
<br>
As Kirk mentioned, as another optimization, triggering a young gc could<br>
free enough regions too.<br></blockquote></div></div><div>Ok, I pass this question to <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Rodrigo </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Bruno and he has the required technical knowledge on the implementation</span>. </div></div></div></div></blockquote><div><br></div><div>It think it is definitively possible to avoid a full GC. </div><div>I only see one advantage of using a full GC, it will maximise the amount of uncommitted memory.  However, this comes at the cost of</div><div>a potentially long pause time.</div><div><br></div><div>We started with this implementation because it was the minimum amount of code changes to have this feature working. </div><div>Besides, in our use case, having a full GC is not a huge problem because applications might be idle anyway.</div><div><br></div><div>Having said that, we can either push this patch with a full GC and then work on a separate patch to avoid a full GC or improve the current</div><div>patch to avoid a full GC. </div><div><br></div><div>What alternative do you think is the best?</div><div><br></div><div>Cheers,</div><div>rodrigo </div><div><br></div></div></div></div>