Skip to main content

very long Total time for which application threads were stopped

3 replies [Last post]
boris_petrovic
Offline
Joined: 2006-11-28
Points: 0

Hi,

I found very annoying GC trace in which GC events register about 20-30 ms, but Total stopped time trace showed 42.7 seconds!!!.
Does anybody have similar experience. I am trying to understand is there wrong "total time trace " gone when gc event took only 35msec.
Application trace below GC trace proves that long pause really happened

Java 1.5.0_12
Siemens Fujitsu RX300 Dual Core Intel(R) Xeon(TM) MP CPU 3.00GHz
SLES 10
Linux version 2.6.16.21-0.8-bigsmp

-Xmx640m -Xms640m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Total time for which application threads were stopped: 0.0235980 seconds
6459.777: [GC 6459.777: [ParNew: 8063K->0K(8128K), 0.0351210 secs] 240456K->233461K(655296K), 0.0355370 secs]
Total time for which application threads were stopped: 42.7288190 seconds
18:33:33,821 WARN [HibernateTemplate] Long commit time: 42780ms for com....

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ysramakrishna
Offline
Joined: 2005-04-25
Points: 0

> I am really not sure about this it really seems very
> strage.
>
> Could it be that finalizers were runnig that long, or
> would this pop up as seperate entry in the log?
>

Boris already found the correct cause of the problem from his google
search, so this response is somewhat moot now, but i wanted to
note that finalizers are not run by the garbage coillector thread
with the mutators stopped. Rather they are run by a so-called
finalizer thread which executes the finalizers concurrently
with the mutators. It is true though that excessive use of finalizers
can also lead to long GC pauses as the GC has to discover
the objects needing finalization and process them on to the
finalization queue whence they will be picked up by the
finalizer thread(s).

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

I am really not sure about this it really seems very strage.

Could it be that finalizers were runnig that long, or would this pop up as seperate entry in the log?

lg Clemens

boris_petrovic
Offline
Joined: 2006-11-28
Points: 0

Hi,

I googled yesterday intensively and found: it states that there is really a bug in HotSpot VM, using multiprocessor machines "Synchronization problem in the pseudo memory barrier code". It is fixed in jdk 1.5.0_14.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2150325
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278

We applied patch yesterday and performed long run test over night and obscure pauses are gone!!!!

Boris