Reclaim of dead humongous objects during young GC.

Thomas Schatzl thomas.schatzl at oracle.com
Tue Sep 8 09:20:00 UTC 2015


Hi,

On Tue, 2015-09-08 at 08:40 +0000, Naman Jain wrote:
> Hey everyone,
>
> I just come across these two options
> G1ReclaimDeadHumongousObjectsAtYoungGC and
> G1TraceReclaimDeadHumongousObjectsAtYoungGC while looking for a
> solution to overcome humongous allocation in G1.
> Can some one tell me whether these options work in java version
> 1.8.0_40 and above or not.

Yes - I even think the feature is enabled by default in 8u40. However we
fixed some cases and improved it slightly in 8u60, so I would recommend
using 8u60.

> If yes, then does humongous object are collected during every young
> GC ?

G1 uses some heuristics to decide whether it should try to reclaim these
regions. First, the technique only applies to arrays of primitive types
(integer, bools, ...) at this time, and they should never have been
referenced by many objects during its lifetime.

It works best (actually extremely well) with applications that are
transaction oriented, where these large temporary objects are kept local
by a thread for things like output buffers.

G1 always applies this technique at every young GC.

Note that in 8u60, the switches have been renamed (iirc), i.e.
G1EagerReclaimHumongousObjects to enable/disable use (default: true),
G1EagerReclaimHumongousObjectsWithStaleRefs to enable some optimization
for it to try to reclaim harder (default: true) and
G1TraceEagerReclaimHumongousObjects (default: false).

G1TraceEagerReclaimHumongousObjects gives some information why (and why
not) particular large objects were reclaimed (or not).

However already with maximum logging (-XX:G1LogLevel=finest) there is
some indication about how effective the technique is/has been applied.

Thanks,
  Thomas




More information about the hotspot-gc-use mailing list