spurious reportings of System.gc()???

[Per Liden]

Hi,

On 04/04/2014 01:23 PM, Kirk Pepperdine wrote:
> Hi Alan,
>
> Thanks for your response.
>
>>
>>>
>>> There are at least two uses of System.gc() inside the JDK itself. The first case is heavy use of ByteBuffer.allocateDirect(), which could cause a System.gc() if reference processing isn't keeping up and you're bumping into the MaxDirectMemorySize limit. I think the other case is heavy use of FileChannel.transferFrom/To(). Maybe that's what you're seeing?
>> I suspect you meant FileChannel.map rather than the transferXXX methods (the transfer methods do use memory mapping for some cases but they unmap so the memory doesn't increase). One thing to mention here is that direct and mapped buffers have instrumentation so if this is JDK 7 or newer then their usage can be monitored with JMX tools.
>>
>> The other one that comes up periodically is RMI as the distributed GC does result in explicit calls to System.gc, Kirk probably knows about that one.
>
> I mentioned RMI in my original email along with the call developers can make to System.gc() or Runtime.gc(). However I would expect that these calls result in a Full collection but all the log records (with the exception of the records labeled as Full GC) look like this;
>
> 0.925: [GC (System.gc())
> Desired Survivor size 11010048 bytes, new threshold 7 (max 15)
> [PSYoungGen: 19838->4025K(76800K)] 19838K->4097K(251392K), 0.0047450 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
>
> That is a young gen collection and hence my confusion.
>
> To be clear my question is; has this call to System.gc() resulted in a young gen collection (and not a full) or is the cause wrong or should this record be treated as a Full GC?

Ah, now I understand what you mean. This is the default behavior for 
ParallelGC. You can disable the young collections in these cases with 
-XX:-ScavengeBeforeFullGC.

cheers,
/Per