Bug in G1GC it performs Full GC when code cache is full resulting in overkill

Martin Makundi martin.makundi at koodaripalvelut.com
Mon Jun 10 06:32:40 PDT 2013


Hi!

>> Does this make sense?
>
> To me, the log indicates that there are multiple threads trying to
> allocate large objects, all of them failing to do so, only then
> triggering the gc.

Sizes of the allocations seem too close to each other to be multiple threads.

Is it possible that the gc is racing against itself in some
re-allocation algorithm?

> I assume you checked that the log messages are not possibly printed
> after the gc? The instrumentation invokes the allocation sampler after
> allocation. So in this case, the threads will block at the allocation,
> wait for gc, and only after that print the expected messages. There may
> also be a delay between the gc output and the allocation information.

I did check, not even a single 30mb allocation in today's log.

> Maybe looking at the code for the instrumentation helps finding this
> issue (this is the first one such bytecode rewriting tool that looked
> simple to use that I found as example).

You mean change instrumentation or debug it? We use exactly this one:
https://code.google.com/p/java-allocation-instrumenter/

**
Martin

>
> Thomas
>
>


More information about the hotspot-gc-use mailing list