G1: no concurrent cycle initiation for humongous allocation

[Thomas Schatzl]

Hi Simone,

  first, sorry for getting back so late....

On Tue, 2013-10-08 at 02:22 +0200, Simone Bordet wrote:
> Resending, as the 100 KiB attached log was rejected.
> I can provide the log separately.
> 
> On Tue, Oct 1, 2013 at 1:28 PM, Simone Bordet <simone.bordet at gmail.com> wrote:
> > Hi,
> >
> > can I use some experience here to interpret the attached log ?
> >
> > Seems to me that G1 is keeping the young gen really small (~50 MiB) to
> > meet the pause goal (100 ms). This results in a high promotion rate of
> > mostly dead objects, so that a marking cycle is able to cleanup 250+
> > MiB (out of a 1 GiB heap).
> > But after the marking cycle, many log lines (10s to 100s) of this kind appear few ms apart from each other:
> >
> > [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle
> > initiation, reason: still doing mixed collections, occupancy:
> > 642777088 bytes, allocation request: 2322928 bytes, threshold:
> > 644245080 bytes (60.00 %), source: concurrent humongous allocation]
> >
> > These lines appear after several seconds (30+) of no GC logging, so
> > the application did not trigger a young GC despite the young gen is
> > really small.
> > Yet, seems to me that G1 thinks the heap is at IHOP despite the marking cycle just
> > freed 250+ MiB, and apparently the application did not allocate more
> > than ~50 MiB (otherwise a young GC would have triggered).
> >

If a humongous/large object allocation makes the occupied heap (after
allocation of the humongous object) larger than the threshold, G1 tries
to schedule a concurrent cycle.

At the same time G1 still in the mixed-gc phase (cleaning up the regular
heap), and the collection policy does not allow initiation of a
concurrent cycle during that phase.

The message in essence just indicates that.

Is there any problem, apart from the messages?

Thomas