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