<div dir="ltr"><div dir="ltr">Hi Thomas,</div><div dir="ltr"><br></div><div>thank you for your fast reply!</div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com">thomas.schatzl@oracle.com</a>> escreveu no dia quarta, 5/09/2018 à(s) 20:13:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rodrigo,<br>
<br>
On Tue, 2018-09-04 at 15:04 +0000, Rodrigo Bruno wrote:<br>
> Hi Thomas,<br>
> <br>
> > Did you ever notice an improvement in heap usage after the first<br>
> > such attempt?<br>
> > There should be none except for memory held by j.l.ref.References.<br>
> > <br>
> > What I want to get at, as a later improvement, we could think of<br>
> > just skipping those then (as except as mentioned for the<br>
> > j.l.ref.References issue there would be "no" difference).<br>
> > <br>
> <br>
> I didn't devise any experiments to measure memory usage. However, we<br>
> can obviously do that.<br>
> <br>
> The new version of the patch regarding <br>
> <br>
> <a href="http://openjdk.java.net/jeps/8204089" rel="noreferrer" target="_blank">http://openjdk.java.net/jeps/8204089</a><br>
> <br>
> can be found at<br>
> <br>
> <a href="http://www.gsd.inesc-id.pt/~rbruno/webrev.zip" rel="noreferrer" target="_blank">http://www.gsd.inesc-id.pt/~rbruno/webrev.zip</a><br>
> <br>
> This version already includes idle compaction (Full GC is optional)<br>
> and your previous comments as well.<br>
> <br>
> Let me know what you think. <br>
<br>
- small tidbit: the change did not update the type of the<br>
_last_heap_resize variable; the webrev does not compile as is because<br>
of the recent introduction to use -Wreorder.<br>
<br></blockquote><div><br></div><div>Oh... I will fix that and send a new version very soon.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- the test crashes here with some assert during resizing (after<br>
concurrent marking) in our regression testing - it does not give any<br>
new errors though, so that is good at least. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I will definitely need to look into this - this may be an existing<br>
issue with (in this case heap shrinking) :)<br>
<br></blockquote><div><br></div><div><div>Which test? I was running the new test in Linux x86_64 slowdebug build</div><div>and not hitting any assert. How did you run it?</div><div><br></div><div>Still regardind tests, it there a way to run the same test with multiple (different) command</div><div>line arguments?</div></div><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">
- it would have been a lot nicer if the sleep_before_next_cycle()<br>
returned some integer/enum which can be acted upon outside of it.<br>
I.e. it is imho much more readable to separate control/decision making<br>
from acting on it compared to separating both in this case. The current<br>
sleep_before_next_cycle() is kind of hacky :) </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I will look into this as well and propose an alternative. This may take<br>
a day or two.<br></blockquote><div><br></div><div>Okay, we can definitely improve the current version of this method.</div><div><br></div><div>Thanks,</div><div>rodrigo </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
  Thomas<br>
<br>
</blockquote></div></div></div>