G1: no concurrent cycle initiation for humongous allocation

[Simone Bordet]

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).
>
> Thanks !
>
> --
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz