From fancyerii at gmail.com Sun Jul 1 20:35:38 2012 From: fancyerii at gmail.com (Li Li) Date: Mon, 2 Jul 2012 11:35:38 +0800 Subject: jstack exception Message-ID: hi all jstack throws NullPointException. my jdk version: java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode) the output of jstack command: jstack -F 17296 Attaching to process ID 17296, please wait... Debugger attached successfully. Server compiler detected. JVM version is 20.2-b06 Deadlock Detection: No deadlocks found. Thread 17330: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Interpreted frame) - sun.misc.GC$Daemon.run() @bci=51, line=100 (Interpreted frame) Thread 17325: (state = BLOCKED) Thread 17324: (state = BLOCKED) Thread 17323: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Interpreted frame) - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=118 (Interpreted frame) - java.lang.ref.ReferenceQueue.remove() @bci=2, line=134 (Interpreted frame) - java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, line=159 (Interpreted frame) Thread 17322: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Interpreted frame) - java.lang.Object.wait() @bci=2, line=485 (Interpreted frame) - java.lang.ref.Reference$ReferenceHandler.run() @bci=46, line=116 (Interpreted frame) Thread 17296: (state = IN_JAVA) Error occurred during stack walking: java.lang.NullPointerException at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:78) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.tools.jstack.JStack.runJStackTool(JStack.java:118) at sun.tools.jstack.JStack.main(JStack.java:84) From rhelbing at icubic.de Mon Jul 9 11:15:37 2012 From: rhelbing at icubic.de (Ralf Helbing) Date: Mon, 09 Jul 2012 20:15:37 +0200 Subject: GC notification oddities Message-ID: <4FFB1FC9.3080000@icubic.de> dear mailing list, I just started to play with GC notifications based on /Jack Shirazi/s example code from http://www.fasterj.com/articles/gcnotifs.shtml. What seems odd is that the reported durations do not match those from plain old GC logging. So I get this output from GC notifications: 2012-07-09 20:04:24 SYSTEM memory IQMemoryWatcher.java:303 - Young Gen GC: - 2 ParNew (from Allocation Failure) 4,435,157 us / 4,435,157 2012-07-09 20:04:24 SYSTEM memory IQMemoryWatcher.java:332 - Par Eden Space (fully expanded) used: 100.0% -> 0.0% (1MB) / CMS Old Gen (still expandable) used: 0.0% -> 0.0% (1MB) / CMS Perm Gen (fully expanded) used: 19.1% -> 19.1% (50MB) / Code Cache (still expandable) used: 99.2% -> 99.2% (18MB) / Par Survivor Space (fully expanded) used: 4.1% -> 99.1% (407MB) / 2012-07-09 20:04:24 SYSTEM memory IQMemoryWatcher.java:337 - GC cumulated overhead 0.4%, total duration: 4,643,408 us 2012-07-09 20:04:43 SYSTEM memory IQMemoryWatcher.java:303 - Young Gen GC: - 3 ParNew (from Allocation Failure) 97,168,327 us / 97,168,327 2012-07-09 20:04:43 SYSTEM memory IQMemoryWatcher.java:332 - Par Eden Space (fully expanded) used: 100.0% -> 0.0% (1MB) / CMS Old Gen (still expandable) used: 0.0% -> 22660.0% (1190MB) / CMS Perm Gen (fully expanded) used: 19.5% -> 19.5% (51MB) / Code Cache (still expandable) used: 99.2% -> 99.2% (20MB) / Par Survivor Space (fully expanded) used: 99.1% -> 100.0% (410MB) / 2012-07-09 20:04:43 SYSTEM memory IQMemoryWatcher.java:337 - GC cumulated overhead 7.4%, total duration: 101,811,735 us and at the same time in GC.log 2012-07-09T20:04:24.106+0200: 77.960: [GC 77.960: [ParNew: 3373086K->415951K(3774912K), 0.3097769 secs] 3373086K->415951K(3780288K), 0.3098689 secs] [Times: user=3.31 sys=0.61, real=0.31 secs] 2012-07-09T20:04:35.746+0200: 89.600: [GC 89.600: [ParNew: 3771471K->419392K(3774912K), 6.7863811 secs] 3771471K->1637595K(5002044K), 6.7866131 secs] [Times: user=40.70 sys=3.45, real=6.79 secs] 2012-07-09T20:04:42.533+0200: 96.387: [GC [1 CMS-initial-mark: 1218203K(1227132K)] 1711538K(5002044K), 0.6360475 secs] [Times: user=0.64 sys=0.00, real=0.64 secs] [?] which seems more plausible. In the first line of each notification, we report the GCInfo#duration(), along with the difference between #endTime() and #startTime(), which seems to match, but without any relation to wall clock or CPU time. Unfortunately, there is no real documentation about time units reported by GCInfo. I used 1.7.0_05 64bit, Windows. What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120709/ff3cd587/attachment.html From john.cuthbertson at oracle.com Mon Jul 9 16:04:33 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 09 Jul 2012 16:04:33 -0700 Subject: GC notification oddities In-Reply-To: <4FFB1FC9.3080000@icubic.de> References: <4FFB1FC9.3080000@icubic.de> Message-ID: <4FFB6381.60000@oracle.com> Hi Ralf, There are somethings that occur during the safepoint that the GC times may not take in to account (for example TLAB retirement) but may be included in the GC notification durations. I'd have to look at the code to determine the full list. How do the GC times and the durations in the GC notifications compare against the output from -XX:+PrintGCApplicationStoppedTime? JohnC On 7/9/2012 11:15 AM, Ralf Helbing wrote: > > dear mailing list, > > I just started to play with GC notifications based on /Jack Shirazi/s > example code from http://www.fasterj.com/articles/gcnotifs.shtml. What > seems odd is that the reported durations do not match those from plain > old GC logging. > So I get this output from GC notifications: > > 2012-07-09 20:04:24 SYSTEM memory IQMemoryWatcher.java:303 > - Young Gen GC: - 2 ParNew (from Allocation Failure) 4,435,157 us / > 4,435,157 > 2012-07-09 20:04:24 SYSTEM memory IQMemoryWatcher.java:332 > - Par Eden Space (fully expanded) used: 100.0% -> 0.0% (1MB) / CMS > Old Gen (still expandable) used: 0.0% -> 0.0% (1MB) / CMS Perm Gen > (fully expanded) used: 19.1% -> 19.1% (50MB) / Code Cache (still > expandable) used: 99.2% -> 99.2% (18MB) / Par Survivor Space (fully > expanded) used: 4.1% -> 99.1% (407MB) / > 2012-07-09 20:04:24 SYSTEM memory IQMemoryWatcher.java:337 > - GC cumulated overhead 0.4%, total duration: 4,643,408 us > > 2012-07-09 20:04:43 SYSTEM memory IQMemoryWatcher.java:303 > - Young Gen GC: - 3 ParNew (from Allocation Failure) 97,168,327 us > / 97,168,327 > 2012-07-09 20:04:43 SYSTEM memory IQMemoryWatcher.java:332 > - Par Eden Space (fully expanded) used: 100.0% -> 0.0% (1MB) / CMS > Old Gen (still expandable) used: 0.0% -> 22660.0% (1190MB) / CMS Perm > Gen (fully expanded) used: 19.5% -> 19.5% (51MB) / Code Cache (still > expandable) used: 99.2% -> 99.2% (20MB) / Par Survivor Space (fully > expanded) used: 99.1% -> 100.0% (410MB) / > 2012-07-09 20:04:43 SYSTEM memory IQMemoryWatcher.java:337 > - GC cumulated overhead 7.4%, total duration: 101,811,735 us > > and at the same time in GC.log > > 2012-07-09T20:04:24.106+0200: 77.960: [GC 77.960: [ParNew: > 3373086K->415951K(3774912K), 0.3097769 secs] > 3373086K->415951K(3780288K), 0.3098689 secs] [Times: user=3.31 > sys=0.61, real=0.31 secs] > 2012-07-09T20:04:35.746+0200: 89.600: [GC 89.600: [ParNew: > 3771471K->419392K(3774912K), 6.7863811 secs] > 3771471K->1637595K(5002044K), 6.7866131 secs] [Times: user=40.70 > sys=3.45, real=6.79 secs] > 2012-07-09T20:04:42.533+0200: 96.387: [GC [1 CMS-initial-mark: > 1218203K(1227132K)] 1711538K(5002044K), 0.6360475 secs] [Times: > user=0.64 sys=0.00, real=0.64 secs] > [?] > > which seems more plausible. In the first line of each notification, we > report the GCInfo#duration(), along with the difference between > #endTime() and #startTime(), which seems to match, but without any > relation to wall clock or CPU time. > Unfortunately, there is no real documentation about time units > reported by GCInfo. > > I used 1.7.0_05 64bit, Windows. > > What am I doing wrong? > > > _______________________________________________ > 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/20120709/b8095d5d/attachment.html From rhelbing at icubic.de Tue Jul 10 04:54:40 2012 From: rhelbing at icubic.de (Ralf Helbing) Date: Tue, 10 Jul 2012 13:54:40 +0200 Subject: GC notification oddities In-Reply-To: <4FFB6381.60000@oracle.com> References: <4FFB1FC9.3080000@icubic.de> <4FFB6381.60000@oracle.com> Message-ID: <4FFC1800.4060409@icubic.de> Am 10.07.2012 01:04, schrieb John Cuthbertson: > Hi Ralf, > > There are somethings that occur during the safepoint that the GC times > may not take in to account (for example TLAB retirement) but may be > included in the GC notification durations. I'd have to look at the > code to determine the full list. How do the GC times and the durations > in the GC notifications compare against the output from > -XX:+PrintGCApplicationStoppedTime? let's see: before the first ParNew, there are 102 stops in the sub-millisecond range, totalling 0.0236405s. Then, we have 2012-07-10T10:49:37.719+0200: 23.053: [GC 23.053: [ParNew: 3356843K->20067K(3774912K), 0.0186376 secs] 3356843K->20067K(3780288K), 0.0187348 secs] [Times: user=0.13 sys=0.00, real=0.02 secs] Total time for which application threads were stopped: 0.0190405 seconds which seems roughly in line. at the same time, notifications report 2012-07-10 10:49:37 Young Gen GC: - 1 ParNew (from Allocation Failure) 266,511 us 2012-07-10 10:49:37 Par Eden Space (fully expanded) used: 100.0% -> 0.0% (1MB) / CMS Old Gen (still expandable) used: 0.0% -> 0.0% (1MB) / CMS Perm Gen (fully expanded) used: 12.1% -> 12.1% (31MB) / Code Cache (still expandable) used: 98.8% -> 98.8% (11MB) / Par Survivor Space (fully expanded) used: 0.3% -> 4.7% (20MB) This is the first collection. Times are off by a factor of 10. A while later, just an example: 2012-07-10T11:29:50.479+0200: 2435.710: [GC 2435.710: [ParNew: 3404672K->41414K(3774912K), 0.0910539 secs] 7114602K->3751514K(11308916K), 0.0911489 secs] [Times: user=1.18 sys=0.01, real=0.09 secs] Total time for which application threads were stopped: 0.0930148 seconds and: 2012-07-10 11:29:50 Young Gen GC: - 258 ParNew (from Allocation Failure) 1,303,481 us 2012-07-10 11:29:50 Par Eden Space (fully expanded) used: 100.0% -> 0.0% (1MB) / CMS Old Gen (still expandable) used: 49.2% -> 49.2% (3624MB) / CMS Perm Gen (fully expanded) used: 23.7% -> 23.7% (61MB) / Code Cache (still expandable) used: 98.7% -> 98.7% (40MB) / Par Survivor Space (fully expanded) used: 11.7% -> 9.8% (41MB) neighbouring entries are 9s away in both directions, so I am certain the log lines match the same GCs. 1,303,481 usare the GCInfo.getDuration() My JVM parameters are -Xss2m -Xmx16G -XX:NewSize=4G -XX:PermSize=256M -XX:+UseConcMarkSweepGC -XX:ParGCCardsPerStrideChunk=4096 -XX:+UseCompressedOops -XX:+DoEscapeAnalysis -XX:+TieredCompilation -Xloggc:logs/gc.log -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintPromotionFailure -XX:+PrintGCApplicationStoppedTime -XX:+PrintFlagsFinal -XX:+LogVMOutput -XX:LogFile=logs/jvm.log-XX:+UnlockDiagnosticVMOptions Numbers are from a dual socket Xeon server, 16 threads. Other machines show the same behaviour. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120710/8b0d4699/attachment.html From emanuel.amaral.couto at gmail.com Wed Jul 11 00:46:02 2012 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Wed, 11 Jul 2012 08:46:02 +0100 Subject: Allocation time Message-ID: Hi, I have a simple question. Does the time to perform a GC in "verbose:gc", "-XX:+PrintGCDetails", "-XX:+PrintGCTimeStamps", include allocation time (in case the generations need to be resized)? -- Emanuel Couto From smourachov at gmail.com Tue Jul 10 15:28:04 2012 From: smourachov at gmail.com (Serguei Mourachov) Date: Tue, 10 Jul 2012 15:28:04 -0700 Subject: GC memory overhead Message-ID: <4FFCAC74.1040206@gmail.com> Hello We have a system what is essentially big concurrent hashmap containing tens of millions of entries for relatively small long-lived objects. We are running it with following GC related parameters: -Xms7168M -Xmx7168M -Xmn256M -XX:+UseParallelOldGC . The code is optimized for GC, with minor collections happening approximately every 5 min and full collections once a week. Looking at the Linux process RSS values we can see that, apparently, JVM is using significant amount of non-heap memory, and major increase in this value happening around time of very first full GC. In our case that "additional" used RAM space is almost 1Gb. So my questions are: is that expected to have such significant non-heap memory consumption? How can we estimate the GC memory overhead based on number of objects and references in the system? Thank you Serguei Mourachov From jon.masamitsu at oracle.com Wed Jul 11 09:45:30 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 11 Jul 2012 09:45:30 -0700 Subject: Allocation time In-Reply-To: References: Message-ID: <4FFDADAA.9050104@oracle.com> For collectors UseSerialGC and UseConcMarkSweepGC the time to grow the generations is not included in the the collection time but is included in the overall time. For example [GC [DefNew : 19648K->2176K(19648K), 4.8844087 secs] 34835K->34135K(63360K), 4.8855619 secs] not included in the 4.8844087 but is included in the 4.8855619 For UseParallelGC it is included in the overall time 0.1939837 [GC [PSYoungGen: 78816K->11248K(78848K)] 158168K->124592K(254976K), 0.1939837 secs] On 7/11/2012 12:46 AM, Emanuel Couto wrote: > Hi, > > I have a simple question. Does the time to perform a GC in > "verbose:gc", "-XX:+PrintGCDetails", "-XX:+PrintGCTimeStamps", include > allocation time (in case the generations need to be resized)? > From java at java4.info Thu Jul 12 09:40:29 2012 From: java at java4.info (Florian Binder) Date: Thu, 12 Jul 2012 18:40:29 +0200 Subject: OutOfMemoryError (on GCOverheadLimit) Message-ID: <4FFEFDFD.8080309@java4.info> Hi Everyone, I have seen an OutOfMemoryError can be thrown even if there would be enough space for the allocation (if it takes more than 98% of time or something like this). But the javadoc of OutOfMemoryError says: "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector." Therefore I thought an OutOfMemoryError can only be thrown if memory is allocated. For the serial and parallel gc this is no problem, because the gc is only triggered on object allocations. But what is with the CMS or G1? When do they throw the OOME if the OverheadLimit is reached? On the next object allocation or immidiately (interrupting the thread[s] at any position)? And which Thread is getting the OOME? Only one, or all? The reason for these questions is that I would like to know if OOME can be thrown only on object allocation or anytime. Is it possible that the following method throws an OOME?: public int sumAll(int[] data) { int sum = 0; for(int i = 0; i < data.length; i++) { sum += data[i]; } return sum; } Thanks, Flo From docete at gmail.com Wed Jul 11 19:52:29 2012 From: docete at gmail.com (Zhenghua Gao) Date: Thu, 12 Jul 2012 10:52:29 +0800 Subject: A really weird GC problem (long GC pause) Message-ID: We run a Hbase cluster on ordinary machines (8 cores, 32GB memory). Our RegionServer takes 16 GB (heap size) memory, and young GC takes less than 1 second normally. However, every now and then there is some periods that young GC may takes hundreds seconds. We have 16GB heap size, and use ParNew and CMS for GC. The GC log is listed below: 2012-07-11T19:41:00.387+0800: 12391.954: [GC Before GC: Statistics for BinaryTreeDictionary: ------------------------------------ Total Free Space: 1200692977 Max Chunk Size: 1200692977 Number of Blocks: 1 Av. Block Size: 1200692977 Tree Height: 1 Before GC: Statistics for BinaryTreeDictionary: ------------------------------------ Total Free Space: 1465991 Max Chunk Size: 1464832 Number of Blocks: 4 Av. Block Size: 366497 Tree Height: 3 13209.843: [ParNew13209.911: [SoftReference, 0 refs, 0.0000120 secs]13209.911: [WeakReference, 93 refs, 0.0000150 secs]13209.911: [FinalReference, 271 refs, 0.0009130 secs]13209.912: [PhantomReference, 10 refs, 0.0000110 secs]13209.912: [JNI Weak Reference, 0.0000030 secs] Desired survivor size 26836992 bytes, new threshold 1 (max 15) - age 1: 39360920 bytes, 39360920 total : 471872K->52416K(471872K), 0.0692990 secs] 7343322K->6979157K(16724800K)After GC: Statistics for BinaryTreeDictionary: ------------------------------------ Total Free Space: 1193619699 Max Chunk Size: 1193619699 Number of Blocks: 1 Av. Block Size: 1193619699 Tree Height: 1 After GC: Statistics for BinaryTreeDictionary: ------------------------------------ Total Free Space: 1465991 Max Chunk Size: 1464832 Number of Blocks: 4 Av. Block Size: 366497 Tree Height: 3 , 0.0695400 secs] [Times: user=0.47 sys=0.12, real=818.01 secs] Is there any clue that i can solve this issue? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120712/344417c9/attachment.html From vitalyd at gmail.com Thu Jul 12 10:52:34 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 12 Jul 2012 13:52:34 -0400 Subject: A really weird GC problem (long GC pause) In-Reply-To: References: Message-ID: Usually when you see things like this (low user and sys time but high real) it's because of heavy swapping. You mention that you use 16gb out of 32 but is there nothing else running on this machine that could be tying up memory? This should be ruled out first, I'd say. Sent from my phone On Jul 12, 2012 1:42 PM, "Zhenghua Gao" wrote: > We run a Hbase cluster on ordinary machines (8 cores, 32GB memory). > Our RegionServer takes 16 GB (heap size) memory, and young GC takes less > than 1 second normally. > However, every now and then there is some periods that young GC may takes > hundreds seconds. > > We have 16GB heap size, and use ParNew and CMS for GC. The GC log is > listed below: > > 2012-07-11T19:41:00.387+0800: 12391.954: [GC Before GC: > Statistics for BinaryTreeDictionary: > ------------------------------------ > Total Free Space: 1200692977 > Max Chunk Size: 1200692977 > Number of Blocks: 1 > Av. Block Size: 1200692977 > Tree Height: 1 > Before GC: > Statistics for BinaryTreeDictionary: > ------------------------------------ > Total Free Space: 1465991 > Max Chunk Size: 1464832 > Number of Blocks: 4 > Av. Block Size: 366497 > Tree Height: 3 > 13209.843: [ParNew13209.911: [SoftReference, 0 refs, 0.0000120 > secs]13209.911: [WeakReference, 93 refs, 0.0000150 secs]13209.911: > [FinalReference, 271 refs, 0.0009130 secs]13209.912: [PhantomReference, 10 > refs, 0.0000110 secs]13209.912: [JNI Weak Reference, 0.0000030 secs] > Desired survivor size 26836992 bytes, new threshold 1 (max 15) > - age 1: 39360920 bytes, 39360920 total > : 471872K->52416K(471872K), 0.0692990 secs] > 7343322K->6979157K(16724800K)After GC: > Statistics for BinaryTreeDictionary: > ------------------------------------ > Total Free Space: 1193619699 > Max Chunk Size: 1193619699 > Number of Blocks: 1 > Av. Block Size: 1193619699 > Tree Height: 1 > After GC: > Statistics for BinaryTreeDictionary: > ------------------------------------ > Total Free Space: 1465991 > Max Chunk Size: 1464832 > Number of Blocks: 4 > Av. Block Size: 366497 > Tree Height: 3 > , 0.0695400 secs] [Times: user=0.47 sys=0.12, real=818.01 secs] > > Is there any clue that i can solve this 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/20120712/c57a8253/attachment.html From jon.masamitsu at oracle.com Thu Jul 12 11:18:09 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 12 Jul 2012 11:18:09 -0700 Subject: OutOfMemoryError (on GCOverheadLimit) In-Reply-To: <4FFEFDFD.8080309@java4.info> References: <4FFEFDFD.8080309@java4.info> Message-ID: <4FFF14E1.3010706@oracle.com> For CMS the determination to throw an OOME for excessive GC overhead is only done at a Full GC. Assuming there are no allocations in your loop, you won't get an OOME in it. Looking at the code I don't think G1 supports this type of OOME. Jon On 07/12/12 09:40, Florian Binder wrote: > Hi Everyone, > > I have seen an OutOfMemoryError can be thrown even if there would be > enough space for the allocation (if it takes more than 98% of time or > something like this). > > But the javadoc of OutOfMemoryError says: > "Thrown when the Java Virtual Machine cannot allocate an object because > it is out of memory, and no more memory could be made available by the > garbage collector." > > Therefore I thought an OutOfMemoryError can only be thrown if memory is > allocated. > > For the serial and parallel gc this is no problem, because the gc is > only triggered on object allocations. But what is with the CMS or G1? > When do they throw the OOME if the OverheadLimit is reached? On the next > object allocation or immidiately (interrupting the thread[s] at any > position)? And which Thread is getting the OOME? Only one, or all? > > The reason for these questions is that I would like to know if OOME can > be thrown only on object allocation or anytime. > > Is it possible that the following method throws an OOME?: > public int sumAll(int[] data) { > int sum = 0; > for(int i = 0; i< data.length; i++) { > sum += data[i]; > } > return sum; > } > > Thanks, > Flo > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From docete at gmail.com Sun Jul 22 19:15:39 2012 From: docete at gmail.com (Zhenghua Gao) Date: Mon, 23 Jul 2012 10:15:39 +0800 Subject: A really weird GC problem (long GC pause) In-Reply-To: References: Message-ID: Actually, there are some other java processes running on this machine(a datanode, a mapreduce node). So, how could I improve the GC pause in this scenario? Expand the physical memory? On Fri, Jul 13, 2012 at 1:52 AM, Vitaly Davidovich wrote: > Usually when you see things like this (low user and sys time but high > real) it's because of heavy swapping. You mention that you use 16gb out of > 32 but is there nothing else running on this machine that could be tying up > memory? This should be ruled out first, I'd say. > > Sent from my phone > On Jul 12, 2012 1:42 PM, "Zhenghua Gao" wrote: > >> We run a Hbase cluster on ordinary machines (8 cores, 32GB memory). >> Our RegionServer takes 16 GB (heap size) memory, and young GC takes less >> than 1 second normally. >> However, every now and then there is some periods that young GC may takes >> hundreds seconds. >> >> We have 16GB heap size, and use ParNew and CMS for GC. The GC log is >> listed below: >> >> 2012-07-11T19:41:00.387+0800: 12391.954: [GC Before GC: >> Statistics for BinaryTreeDictionary: >> ------------------------------------ >> Total Free Space: 1200692977 >> Max Chunk Size: 1200692977 >> Number of Blocks: 1 >> Av. Block Size: 1200692977 >> Tree Height: 1 >> Before GC: >> Statistics for BinaryTreeDictionary: >> ------------------------------------ >> Total Free Space: 1465991 >> Max Chunk Size: 1464832 >> Number of Blocks: 4 >> Av. Block Size: 366497 >> Tree Height: 3 >> 13209.843: [ParNew13209.911: [SoftReference, 0 refs, 0.0000120 >> secs]13209.911: [WeakReference, 93 refs, 0.0000150 secs]13209.911: >> [FinalReference, 271 refs, 0.0009130 secs]13209.912: [PhantomReference, 10 >> refs, 0.0000110 secs]13209.912: [JNI Weak Reference, 0.0000030 secs] >> Desired survivor size 26836992 bytes, new threshold 1 (max 15) >> - age 1: 39360920 bytes, 39360920 total >> : 471872K->52416K(471872K), 0.0692990 secs] >> 7343322K->6979157K(16724800K)After GC: >> Statistics for BinaryTreeDictionary: >> ------------------------------------ >> Total Free Space: 1193619699 >> Max Chunk Size: 1193619699 >> Number of Blocks: 1 >> Av. Block Size: 1193619699 >> Tree Height: 1 >> After GC: >> Statistics for BinaryTreeDictionary: >> ------------------------------------ >> Total Free Space: 1465991 >> Max Chunk Size: 1464832 >> Number of Blocks: 4 >> Av. Block Size: 366497 >> Tree Height: 3 >> , 0.0695400 secs] [Times: user=0.47 sys=0.12, real=818.01 secs] >> >> Is there any clue that i can solve this 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/20120723/146d6f9d/attachment.html