RFR: bug: Timely Reducing Unused Committed Memory

[Rodrigo Bruno]

Hi,

please see inline:

2018-08-20 12:10 GMT+02:00 Thomas Schatzl <thomas.schatzl at oracle.com>:

> Hi,
>
> On Sun, 2018-08-19 at 22:25 +0200, Rodrigo Bruno wrote:
> > Hi Thomas,
> >
> > I am just wrapping up the patch with the new changes.
> >
> > Three questions:
> >
> > 1 - regarding "use Ticks/Tickspan to measure time"
> >
> > Currently I was using CollectedHeap::last_full_collection to get the
> > time of the last attemp to compact/shrink. Since we are now giving
> > the opportunity to shrink the heap without a full GC, would it make
> > sense to have a different counter (last_compaction_attemp or
> > something) that would be updated
> > inside resize_if_necessary_after_full_collection?
>
> That seems fine.
>

Ack.


>
> >
> > 2 - what checks should we have inside should_idle_compaction
> > (previous should_gc)?
> > Right now we have:
> > a) time since last compaction attempt,
> > b) committed memory above user-defined threshold,
> > c) over committed mem is above used-defined threshold, and
> > d) load average is above user-defined threshold.
>
> I think these are the checks as mentioned in the JEP. Do you see a
> reason to skip one or the other?
>

No, sorry for the question. I will maintain as mentioned in the JEP.


>
> > 3 - it can happen now that two Concurrent Cycles are triggered with
> > no collection in between.
>
> I.e. if the idle timeout is hit multiple times with the option to not
> do a full compaction? Just to make sure I understand the situation.
>

Correct.


>
> > This breakes debug build asserts because we never
> > call  G1ConcurrentMark::post_initial_mark.
> > We cannot call directly from within CM main loop because we are
> > outside a safepoint. Any ideas?
> > Should we setup the next phase (i.e. call post_initial_mark) upon the
> > Cleanup phase?
>
> This will not work: G1ConcurrentMark::post_initial_mark() needs to be
> called in a safepoint as the initial setup of marking needs to capture
> the state of the heap atomically wrt to mutators. Forcing an initial-
> mark gc (with safepoint) seems to be the way to go here.
>
> Look at G1CollectedHeap::attempt_allocation_humongous() to see how this
> is done for humongous allocations. Basically a call to
> G1CollectedHeap::collect() with a new, specific
> "GCCause::g1_idle_timeout_no_fullgc" (for example) value.
>

Okay, will do so.

Thanks,
rodrigo


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