RFR: bug: Timely Reducing Unused Committed Memory

[Rodrigo Bruno]

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,
> >
> > > Did you ever notice an improvement in heap usage after the first
> > > such attempt?
> > > There should be none except for memory held by j.l.ref.References.
> > >
> > > What I want to get at, as a later improvement, we could think of
> > > just skipping those then (as except as mentioned for the
> > > j.l.ref.References issue there would be "no" difference).
> > >
> >
> > I didn't devise any experiments to measure memory usage. However, we
> > can obviously do that.
> >
> > 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.
>
> - small tidbit: the change did not update the type of the
> _last_heap_resize variable; the webrev does not compile as is because
> of the recent introduction to use -Wreorder.
>
>
Oh... I will fix that and send a new version very soon.


> - 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?

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


> - 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,
rodrigo


>
> Thanks,
>   Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180905/e230de89/attachment.htm>