G1: SoftReference, 0 refs, 31.0027203 secs

[Jon Masamitsu]

On 7/16/2015 1:16 AM, Simone Bordet wrote:
> Hi,
>
> I have an application that reported very large (around 30 s) times to
> process *zero* SoftReferences, for example:
>
> 6015.665: [SoftReference, 0 refs, 23.0169525 secs]6038.682:
> [WeakReference, 1 refs, 0.0046033 secs]6038.687: [FinalReference,
> 31647 refs, 0.0090301 secs]6038.696: [PhantomReference, 241 refs,
> 0.0048419 secs]6038.701: [JNI Weak Reference, 0.0000463 secs],
> 23.2166772 secs]
>
> We have been hit by this anomaly a few times now, and in the attached
> logs (that also show the command line flags) it happened 3 times: at
> uptimes 6015.512, 6074.487, 6141.161.

I noted that the entries for these times all have short user times and
long real times.

  [Times: user=3.63 sys=0.00, real=23.22 secs]
  [Times: user=1.54 sys=0.08, real=31.41 secs]
  [Times: user=2.68 sys=0.79, real=29.95 secs

I see that you don't expect other processes to be
interfering (no busy disk I/O or swapping as you say below)
but maybe something else is going on in the system
that is showing up as the SoftRef processing time.
I don't know why it would always show up as SoftRef
time though Kim suggests that it might be incorrect
attribution.  This happens on multiple systems?

Jon
>
> What happens after these long pauses is that G1 goes into "GC overhead
> mode", tries to expand the heap (which fails because it's already
> expanded), but keeps the Eden at a very small size, resulting in a
> series of back-to-back collections that lasted almost 3 minutes where
> the MMU dropped making the application almost unusable.
> After that, G1 was able to recover to normal behavior.
>
> I was wondering if anyone knows a little more about this issue (long
> times to process zero soft references), or whether it has been fixed
> in more recent releases.
>
> We are not aware of any other process that could have caused this such
> as busy disk I/O or swapping (the machine has plenty of memory left
> and it is dedicated to the JVM), but we'll run jHiccup next time.
> However, the fact that it always happened during the processing of
> soft references seems suspicious.
>
> Should I file an issue ?
>
> Thanks !
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20150722/4c8502d0/attachment.html>