RFR: bug: Timely Reducing Unused Committed Memory

[Thomas Schatzl]

Hi,

On Wed, 2018-09-05 at 23:52 +0000, Rodrigo Bruno wrote:
> Hi Thomas,
> 
> thank you for your fast reply!
> 
> Thomas Schatzl <thomas.schatzl at oracle.com> escreveu no dia quarta,
> 5/09/2018 à(s) 20:13:
> > Hi Rodrigo,
> > 
> > On Tue, 2018-09-04 at 15:04 +0000, Rodrigo Bruno wrote:
> > > Hi Thomas,
> > [...]
> > > The new version of the patch regarding 
> > > 
> > > http://openjdk.java.net/jeps/8204089
> > > 
> > > can be found at
> > > 
> > > http://www.gsd.inesc-id.pt/~rbruno/webrev.zip
> > > 
> > > This version already includes idle compaction (Full GC is
> > optional)
> > > and your previous comments as well.
> > > 
> > > Let me know what you think. 
> > 
[...]
> > - the test crashes here with some assert during resizing (after
> > concurrent marking) in our regression testing - it does not give
> > any
> > new errors though, so that is good at least. 
> > I will definitely need to look into this - this may be an existing
> > issue with (in this case heap shrinking) :)
> > 
> 
> Which test? I was running the new test in Linux x86_64 slowdebug
> build and not hitting any assert. How did you run it?

The new TestTimelyCompaction test. There were no particular additoinal
options; however since the @run statement did not contain e.g. heap
size specification the issue might have been resulting from the fact
that we run on different machines than you.

> 
> Still regardind tests, it there a way to run the same test with
> multiple (different) command line arguments?

You can use multiple @run statements in a single test.

> > - it would have been a lot nicer if the sleep_before_next_cycle()
> > returned some integer/enum which can be acted upon outside of it.
> > I.e. it is imho much more readable to separate control/decision
> > making from acting on it compared to separating both in this case.
> > The current sleep_before_next_cycle() is kind of hacky :) 
> > I will look into this as well and propose an alternative. This may
> > take a day or two.
> 
> Okay, we can definitely improve the current version of this method.

:)

Thanks,
  Thomas