RFR: bug: Timely Reducing Unused Committed Memory
Thomas Schatzl
thomas.schatzl at oracle.com
Wed Sep 5 18:23:43 UTC 2018
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.
- 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) :)
- 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.
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list