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