Long GC pauses due to 'wb processing'

Hi all,
I'm in the process of evaluating/optimizing JRockit for a standalone application we're developing with a really large heap (around 40GB), and after reading about EVERY guide and forum thread there is about GC tuning I think I got a pretty good understanding about whats going on in the JVM. But there's still one thing thats killing me and I cant seem to find a single mention of it anywhere, and thats 'wb processing' which happens during old collections while all threads are stopped, even with concurrent garbage collector. E.g.
[INFO ][gcpause] (pause includes wb processing: 4142.326 ms, compaction: 6.892 ms (external), update ref: 0.002 ms)
Most of the time the pauses are fine, maybe 100-200ms which is totally ok, but there are occasional spikes that take up several seconds (I've seen up to 15s), and since I'm trying to optimize for pausetime thats really, really bad.
Now before I start going into details of our application and start doing JRA recordings or sending you logs and stuff: could you maybe tell me whats exactly happening during that phase? Is that a common problem or is it normal behaviour? And can it be avoided somehow?
Any help is appreciated.
Regards,
Matthias

When it comes to the stopping of Java threads there are usually one of two things that is the problem:
1) Roll forwarding takes too long. This is at least easy to debug. Run with -Xverbose:thread=debug. You might get debug info saying:
Thread X (NAME) stopped roll forwarding (5 times, rfLimit: 100), will sleep and try again.
This is not a problem. However, if you see the info-level output saying
Thread X (NAME) stopped roll forwarding (100 times, rfLimit: 100), will do unlimited roll forwarding
Then you probably have a problem. What happens is that if we roll forward too long without finding a safe place to stop a Java thread, we release the thread, let it run for a short while and then try to stop it again. We do this a maximum of 100 times, then we do unlimited roll forwarding. If this happen, we can roll forward for a very long time.
The solution for this is to run with the flag "-XXrollforwardretrylimit:-1". This will allow us to bail from a roll forward unlimited amount of times without falling back to unlimited roll forwarding.
2) The other common problem with stopping of Java threads is that the application is blocking signals. JRockit is using signals to stop threads, but some operations stops signals on an OS level. The most common of these operations is reading and writing to a NFS share. This is a linux limitation.
To debug this, I would suggest taking a JRA recording with Latency data (see http://download.oracle.com/docs/cd/E13188_01/jrockit/geninfo/diagnos/intromiscon.html#wp1077578). This will show file io events, and you can search for long latencies there.

Similar Messages

Strange Long ParNewGC Pauses During Application Startup

Recently we started seeing long ParNewGC pauses when starting up Kafka that were causing session timeouts:
[2015-04-24 13:26:23,244] INFO 0 successfully elected as leader (kafka.server.ZookeeperLeaderElector)
2.111: [GC (Allocation Failure) 2.111: [ParNew: 136320K->10236K(153344K), 0.0235777 secs] 648320K->522236K(2080128K), 0.0237092 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]
2.599: [GC (Allocation Failure) 2.599: [ParNew: 146556K->3201K(153344K), 9.1514626 secs] 658556K->519191K(2080128K), 9.1515757 secs] [Times: user=18.25 sys=0.01, real=9.15 secs]
[2015-04-24 13:26:33,443] INFO New leader is 0 (kafka.server.ZookeeperLeaderElector$LeaderChangeListener)
After much investigation I found that the trigger was the allocation of a 500M static object early in the startup code. It of course makes no sense that a single large static object in Old memory would impact ParNew collections, but, it does seem to. I have created a bug report, but, it is still under investigation.
I have reproduced the problem with a simple application on several Linux platforms including an EC2 instance and the following JREs:
OpenJDK: 6, 7, and 8
Oracle: 7 and 8
Oracle 6 does not seem to have an issue. All the ParNewGC times are small.
Here is the simple program that demonstrates the issue:
import java.util.ArrayList;
public class LongParNewPause {
   static byte[] bigStaticObject;
   public static void main(String[] args) throws Exception {
   int bigObjSize = args.length > 0 ? Integer.parseInt(args[0]) : 524288000;
   int littleObjSize = args.length > 1 ? Integer.parseInt(args[1]) : 100;
   int saveFraction = args.length > 2 ? Integer.parseInt(args[2]) : 10;
   bigStaticObject = new byte[bigObjSize];
ArrayList<byte[]> holder = new ArrayList<byte[]>();
   int i = 0;
   while (true) {
   byte[] local = new byte[littleObjSize];
   if (i++ % saveFraction == 0) {
holder.add(local);
I run it with the following options:
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx2G -Xms2G
Note that I have not seen the issue with 1G heaps. 4G heaps exhibit the issue (as do heaps as small as 1.2G)
Here is the output:
0.321: [GC (Allocation Failure) 0.321: [ParNew: 272640K->27329K(306688K), 0.0140537 secs] 784640K->539329K(2063104K), 0.0141584 secs] [Times: user=0.05 sys=0.02, real=0.02 secs]
0.368: [GC (Allocation Failure) 0.368: [ParNew: 299969K->34048K(306688K), 0.7655383 secs] 811969K->572321K(2063104K), 0.7656172 secs] [Times: user=2.89 sys=0.02, real=0.77 secs]
1.165: [GC (Allocation Failure) 1.165: [ParNew: 306688K->34048K(306688K), 13.8395969 secs] 844961K->599389K(2063104K), 13.8396650 secs] [Times: user=54.38 sys=0.05, real=13.84 secs]
15.036: [GC (Allocation Failure) 15.036: [ParNew: 306688K->34048K(306688K), 0.0287254 secs] 872029K->628028K(2063104K), 0.0287876 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
15.096: [GC (Allocation Failure) 15.096: [ParNew: 306688K->34048K(306688K), 0.0340727 secs] 900668K->657717K(2063104K), 0.0341386 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
Even stranger is the fact that the problem seems to be limited to objects in the range of about 480M to 512M. Specifically:
[503316465,536870384]
Values outside this range appear to be OK. Anyone have any thoughts? Can you reproduce the issue on your machine?

I have started a discussion on this issue on the hotspot-gc-dev list:
Strange Long ParNew GC Pauses (Sample Code Included)
One of the engineers on that list was able to reproduce the issue and there is some discussion there about what might be going on. I am a GC novice, but, am of the opinion that there is a bug to be found in the ParNew GC code introduced in Java 7.
Here is a more frightening example. The ParNew GCs keeping getting longer and longer - it never stabilized like the previous example I sent did. I killed the process once the ParNew GC times reached almost 1 minute each.
Bad Case - 500M Static Object:
java -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx6G -Xms6G LongParNewPause $((500*1024*1024)) 100 100
0.309: [GC0.309: [ParNew: 272640K->3028K(306688K), 0.0287780 secs] 784640K->515028K(6257408K), 0.0288700 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
0.372: [GC0.372: [ParNew: 275668K->7062K(306688K), 0.0228070 secs] 787668K->519062K(6257408K), 0.0228580 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
0.430: [GC0.430: [ParNew: 279702K->11314K(306688K), 0.0327930 secs] 791702K->523314K(6257408K), 0.0328510 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
0.497: [GC0.497: [ParNew: 283954K->15383K(306688K), 0.0336020 secs] 795954K->527383K(6257408K), 0.0336550 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
0.565: [GC0.565: [ParNew: 288023K->21006K(306688K), 0.0282110 secs] 800023K->533006K(6257408K), 0.0282740 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
0.627: [GC0.627: [ParNew: 293646K->26805K(306688K), 0.0265270 secs] 805646K->538805K(6257408K), 0.0266220 secs] [Times: user=0.07 sys=0.01, real=0.03 secs]
0.688: [GC0.688: [ParNew: 299445K->20215K(306688K), 1.3657150 secs] 811445K->535105K(6257408K), 1.3657830 secs] [Times: user=3.97 sys=0.01, real=1.36 secs]
2.087: [GC2.087: [ParNew: 292855K->17914K(306688K), 6.6188870 secs] 807745K->535501K(6257408K), 6.6189490 secs] [Times: user=19.71 sys=0.03, real=6.61 secs]
8.741: [GC8.741: [ParNew: 290554K->17433K(306688K), 14.2495190 secs] 808141K->537744K(6257408K), 14.2495830 secs] [Times: user=42.34 sys=0.10, real=14.25 secs]
23.025: [GC23.025: [ParNew: 290073K->17315K(306688K), 21.1579920 secs] 810384K->540348K(6257408K), 21.1580510 secs] [Times: user=70.10 sys=0.08, real=21.16 secs]
44.216: [GC44.216: [ParNew: 289955K->17758K(306688K), 27.6932380 secs] 812988K->543511K(6257408K), 27.6933060 secs] [Times: user=103.91 sys=0.16, real=27.69 secs]
71.941: [GC71.941: [ParNew: 290398K->17745K(306688K), 35.1077720 secs] 816151K->546225K(6257408K), 35.1078600 secs] [Times: user=130.86 sys=0.10, real=35.11 secs]
107.081: [GC107.081: [ParNew: 290385K->21826K(306688K), 41.4425020 secs] 818865K->553022K(6257408K), 41.4425720 secs] [Times: user=158.25 sys=0.31, real=41.44 secs]
148.555: [GC148.555: [ParNew: 294466K->21834K(306688K), 45.9826660 secs] 825662K->555757K(6257408K), 45.9827260 secs] [Times: user=180.91 sys=0.14, real=45.98 secs]
194.570: [GC194.570: [ParNew: 294474K->21836K(306688K), 51.5779770 secs] 828397K->558485K(6257408K), 51.5780450 secs] [Times: user=204.05 sys=0.20, real=51.58 secs]
246.180: [GC246.180: [ParNew^C: 294476K->18454K(306688K), 58.9307800 secs] 831125K->557829K(6257408K), 58.9308660 secs] [Times: user=232.31 sys=0.23, real=58.93 secs]
Heap
par new generation   total 306688K, used 40308K [0x000000067ae00000, 0x000000068fac0000, 0x000000068fac0000)
   eden space 272640K,   8% used [0x000000067ae00000, 0x000000067c357980, 0x000000068b840000)
   from space 34048K, 54% used [0x000000068b840000, 0x000000068ca458f8, 0x000000068d980000)
   to   space 34048K,   0% used [0x000000068d980000, 0x000000068d980000, 0x000000068fac0000)
concurrent mark-sweep generation total 5950720K, used 539375K [0x000000068fac0000, 0x00000007fae00000, 0x00000007fae00000)
concurrent-mark-sweep perm gen total 21248K, used 2435K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)
Good Case - 479M Static Object:
java -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx6G -Xms6G LongParNewPause $((479*1024*1024)) 100 100
0.298: [GC0.298: [ParNew: 272640K->3036K(306688K), 0.0152390 secs] 763136K->493532K(6257408K), 0.0153450 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.346: [GC0.346: [ParNew: 275676K->7769K(306688K), 0.0193840 secs] 766172K->498265K(6257408K), 0.0194570 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
0.398: [GC0.398: [ParNew: 280409K->11314K(306688K), 0.0203460 secs] 770905K->501810K(6257408K), 0.0204080 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.450: [GC0.450: [ParNew: 283954K->17306K(306688K), 0.0222390 secs] 774450K->507802K(6257408K), 0.0223070 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.504: [GC0.504: [ParNew: 289946K->18380K(306688K), 0.0169000 secs] 780442K->508876K(6257408K), 0.0169630 secs] [Times: user=0.07 sys=0.01, real=0.02 secs]
0.552: [GC0.552: [ParNew: 291020K->26805K(306688K), 0.0203990 secs] 781516K->517301K(6257408K), 0.0204620 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.604: [GC0.604: [ParNew: 299445K->21153K(306688K), 0.0230980 secs] 789941K->514539K(6257408K), 0.0231610 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.659: [GC0.659: [ParNew: 293793K->29415K(306688K), 0.0170240 secs] 787179K->525498K(6257408K), 0.0170970 secs] [Times: user=0.07 sys=0.01, real=0.02 secs]
0.708: [GC0.708: [ParNew: 302055K->23874K(306688K), 0.0202970 secs] 798138K->522681K(6257408K), 0.0203600 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.759: [GC0.760: [ParNew: 296514K->26842K(306688K), 0.0238600 secs] 795321K->528371K(6257408K), 0.0239390 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
0.815: [GC0.815: [ParNew: 299482K->25343K(306688K), 0.0237580 secs] 801011K->529592K(6257408K), 0.0238030 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]
0.870: [GC0.870: [ParNew: 297983K->25767K(306688K), 0.0195800 secs] 802232K->532743K(6257408K), 0.0196290 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
0.921: [GC0.921: [ParNew: 298407K->21795K(306688K), 0.0196310 secs] 805383K->531488K(6257408K), 0.0196960 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
0.972: [GC0.972: [ParNew: 294435K->25910K(306688K), 0.0242780 secs] 804128K->538329K(6257408K), 0.0243440 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
1.028: [GC1.028: [ParNew: 298550K->21834K(306688K), 0.0235000 secs] 810969K->536979K(6257408K), 0.0235600 secs] [Times: user=0.06 sys=0.00, real=0.03 secs]
1.083: [GC1.083: [ParNew: 294474K->26625K(306688K), 0.0188330 secs] 809619K->544497K(6257408K), 0.0188950 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
1.133: [GC1.133: [ParNew: 299265K->26602K(306688K), 0.0210780 secs] 817137K->547186K(6257408K), 0.0211380 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
1.185: [GC1.185: [ParNew: 299242K->26612K(306688K), 0.0236720 secs] 819826K->549922K(6257408K), 0.0237230 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
1.240: [GC1.241: [ParNew: 299252K->26615K(306688K), 0.0188560 secs] 822562K->552651K(6257408K), 0.0189150 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.291: [GC1.291: [ParNew: 299255K->26615K(306688K), 0.0195090 secs] 825291K->555378K(6257408K), 0.0195870 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.342: [GC1.342: [ParNew: 299255K->22531K(306688K), 0.0229010 secs] 828018K->554021K(6257408K), 0.0229610 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.396: [GC1.396: [ParNew: 295171K->24505K(306688K), 0.0265920 secs] 826661K->560810K(6257408K), 0.0266360 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
1.453: [GC1.453: [ParNew: 297145K->24529K(306688K), 0.0296490 secs] 833450K->563560K(6257408K), 0.0297070 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
1.514: [GC1.514: [ParNew: 297169K->27700K(306688K), 0.0259820 secs] 836200K->569458K(6257408K), 0.0260310 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.571: [GC1.572: [ParNew: 300340K->27666K(306688K), 0.0199210 secs] 842098K->572150K(6257408K), 0.0199650 secs] [Times: user=0.07 sys=0.01, real=0.02 secs]
1.623: [GC1.623: [ParNew: 300306K->27658K(306688K), 0.0237020 secs] 844790K->574868K(6257408K), 0.0237630 secs] [Times: user=0.08 sys=0.00, real=0.02 secs]
1.678: [GC1.678: [ParNew: 300298K->31737K(306688K), 0.0237820 secs] 847508K->581674K(6257408K), 0.0238530 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
1.733: [GC1.733: [ParNew: 304377K->21022K(306688K), 0.0265400 secs] 854314K->573685K(6257408K), 0.0265980 secs] [Times: user=0.08 sys=0.00, real=0.02 secs]
1.791: [GC1.791: [ParNew: 293662K->25359K(306688K), 0.0249520 secs] 846325K->580748K(6257408K), 0.0250050 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.847: [GC1.847: [ParNew: 297999K->19930K(306688K), 0.0195120 secs] 853388K->581179K(6257408K), 0.0195650 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
1.898: [GC1.898: [ParNew: 292570K->20318K(306688K), 0.0233960 secs] 853819K->584294K(6257408K), 0.0234650 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
1.953: [GC1.953: [ParNew: 292958K->20415K(306688K), 0.0233530 secs] 856934K->587117K(6257408K), 0.0234130 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
2.007: [GC2.007: [ParNew: 293055K->20439K(306688K), 0.0301410 secs] 859757K->589868K(6257408K), 0.0302070 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
2.068: [GC2.068: [ParNew: 293079K->20445K(306688K), 0.0289190 secs] 862508K->592600K(6257408K), 0.0289690 secs] [Times: user=0.09 sys=0.00, real=0.03 secs]
^C2.129: [GC2.129: [ParNew: 293085K->29284K(306688K), 0.0218880 secs] 865240K->604166K(6257408K), 0.0219350 secs] [Times: user=0.09 sys=0.00, real=0.02 secs]
Heap
par new generation   total 306688K, used 40135K [0x000000067ae00000, 0x000000068fac0000, 0x000000068fac0000)
   eden space 272640K,   3% used [0x000000067ae00000, 0x000000067b898a78, 0x000000068b840000)
   from space 34048K, 86% used [0x000000068d980000, 0x000000068f619320, 0x000000068fac0000)
   to   space 34048K,   0% used [0x000000068b840000, 0x000000068b840000, 0x000000068d980000)
concurrent mark-sweep generation total 5950720K, used 574881K [0x000000068fac0000, 0x00000007fae00000, 0x00000007fae00000)
concurrent-mark-sweep perm gen total 21248K, used 2435K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)

Hyper-V 2012 R2 - Fixed Size VHDX Have VMs Paused Due to Disk Space Shortage

I am running Hyper-V Server 2012 R2 (Server Core). I have an SSD boot drive and a 10 Tb Storage Space HDD (Double Pairty - RAID6) where all VMs are stored.
I have one VM setup with an expanding VHDX file. It is setup with thin provisioning for 2 Tb and about 1.5 Tb is currently used. The VM paused due to physical disk space (SS drive) being low. I turned off this VM and tried to start a different
VM that has two fixed size VHDX files (also on the SS drive). This second VM would not start either. I got the same error message, as occurred on the first VM, about the physical disk space being low. There was about 10-20 Mb of physical
space left of my SS HDD when these errors occurred.
Given the first VM is setup with an expanding VHDX that makes sense to me that at some point there may not be enough physical disk space for the VM to expand and continue to run.
But given my second VM is using a fixed VHDX it doesn't make sense to me that I cannot get this VM to start. Even if the Storage Space disk were completely full I would expect this VM to be able to start?
Thanks for any assistance you can provide.
Theokrat

Hi Theokrat,
"The HDD was setup with approximately 5 Tb storage pool as double parity."
"My first VM has a 4 Tb fixed VHDX. Thus there was only about
1 Tb free space left for the second VM."
"And for the VMs I'm asking about I set up those options to point to my HDD which is the D drive."
So, there are two VMs (the first VM has 4TB disk , the
second VM has 1TB disk )and all of the VMs' files
are stored on the 5TB HDD (the 1TB VHDx is dynamical) .
You turned off the second VM when it was paused due to lacking of disk space (before this the first VM is off ).
When you start the first VM , it still can not start and the error arose again ,right ?
If there is no any other factor led to disk usage increasing , I think the issue might be the startup memory of first VM is larger than or equal to the second VM's .
Please try to check that , if it is true , you can try to set lower memory for the first VM then start it again .
Best Regards
Elton JI
We
are trying to better understand customer views on social support experience, so your participation in this
interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

How long is the life time of process scope variable ?

Hi All,
How long is the life time of process scope variable befoer it expires ?
Is it the same with the life time of session scope ?
How can we set the value in OAS when deployment ?
Thank you,
xtanto

Hi,
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/devguide/communicatingBetweenPages.html
" Finally, processScope never empties itself; the only way to clear processScope is to manually force it to clear:
AdfFacesContext afContext = AdfFacesContext.getCurrentInstance();
afContext.getProcessScope().clear();
Otherwise the variable lives for the duration of the window process. The referenced document above also shows how to set a variable to process scope
Frank

Why couldn't I finish install Photoshop Elements 11 due to conflicting processes running?

On my iMac7,1 running Mac OS X 10.8.3, I have installed Photoshop Elements 10 and Premiere Elements 10. I bought Photoshop Elements 11 (& Premiere Elements 11) at a retail store and began installing Photoshop Elements 11 from the DVD from the retail store. The install software accepted the Photoshop Elements 11 serial number that found on the DVD packaging and entered at the prompt, but then I could not continue the install due to 3 processes that the install said were running. I had previously shut off my virus protection software and could only see one application, other than the installer, running (iClock), so I was puzzled how to shut down these 3 processes:
ElementsAutoAnalyzer
PhotoshopServer
dynamiclinkmanager
I suppose I could have gone to the Activity Monitor.app to see if they showed up running there, but that seems pretty extreme for a simple install of a standard appication like Photoshop Elements ... so I went to Adobe chat support and explained the problem in some detail. The support professional told me that this problem was beyond his expertise and suggested I call the phone support service. Does anyone know what I did wrong?
Here is the error message that I got when I quit the install:
Installation Status
Installation was cancelled
Exit Code: 24
-------------------------------------- Summary --------------------------------------
- 0 fatal error(s), 1 error(s), 0 warning(s)
ERROR: DW046: Following Conflicting processes were running -
block:ElementsAutoAnalyzer{|}block:PhotoshopServer{|}block:

Extreme or not, activity monitor is the place to stop them. I would also go to the organizer preferences>media analysis and put a final stop to the auto analyzer unless for some reason you want PSE to pass judgment on your photos.

How long should I let the extracting process run? It has been over 6 hours (Photoshop Elements.

How long should I let the extracting process run? It has been over 6 hours (Photoshop Elements). I have already received Disk Image Error - 4960. System will not let me attempt another download as message that download is in queue is received??

Cancel it, try this:
Direct Download Links for Adobe Software
Use Winzip to extract the 7z file.
Mylenium

Prevent long GC pauses

Hello,
I'm using jdk1.6.
The problem is, that sometimes I'm facing a long gc pause, specially during "concurrent mode failure".
Is there any option for jvm to set a max AppStopTime? And what could be the impact setting such a option ?
Here are the jvm settings I'm currently using:
-Xms4G -Xmx4G -XX:MaxNewSize=128M -XX:NewSize=128M -XX:MaxPermSize=256M -XX:PermSize=256M"
-server -showversion -Xbatch -XX:+UseLargePages -XX:LargePageSizeInBytes=32M
-XX:+UseParNewGC -XX:ParallelGCThreads=4 -XX:ParallelGCToSpaceAllocBufferSize=192k -XX:SurvivorRatio=6 -XX:TargetSurvivo
rRatio=75 -XX:+UseConcMarkSweepGC -XX:CMSMarkStackSize=32M -XX:CMSMarkStackSizeMax=32M -XX:+CMSParallelRemarkEnabled -XX:-CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC'
Afaik there is no other chance to improve gc settings. Do you see any other possibilities ?
Thanks,
Christian

Depending on how long lived the majority of the objects in your heap are you can better adjust the sizes of the new and old generation spaces. If short lived, make your new gen space larger. You could make it as large as half your total heap using "-XX:NewRatio=1". (NewRatio would replace using MaxNewSize)
How do you know if objects are short lived or long lived? If you watch the action in your heap with VisualGC/Visual VM, and in the display you see everything get cleaned up in the eden & survivor spaces with each GC, then you probably have mostly short lived objects.
You may also see that your survivor spaces are too small. If too small, objects get promoted to the old generation space too quickly, filling up your old gen space unnecessarily, and creating long GC pauses.
The best situation is where eden and the survivior spaces are sized such that as many as possible objects get cleaned up on an ongoing basis without them moving to the old generation space as they age.

I purchased a ipod 5th generation 2 weeks ago and its still processing! how long does it usually take 2 process

i purchased a ipod 5th generation 2 weeks ago and its still processing! how long does it usually take 2 process??

See this ungoing discussion:
https://discussions.apple.com/thread/4384899?tstart=0

Hi, can iMovie give pronlems during the boot process from my iMac Mine. I have often after working with iMovie that i get during the boot Psi SDXH pause so the boot process stops

hi,
can iMovie give problems during the boot process from my iMac Mini?
I have often, after working with iMovie that i get during the boot Psi SDXH pause
so the boot process stops at this point
I have often reinstall OSX Mavericks
regards,
HenkfromWinterswijk
Netherlands

Hello Federico,
Your EliteBook is a Business model. Your issue would be best answered on the HP Enterprise Business Community Forum
Good luck!
↙-----------How do I give Kudos?| How do I mark a post as Solved? ----------------↓

CMS collector taking too long pauses due to fragmentation

we are using Weblogic 10gR3 servers with JDK 160_23 for ODSI application and using CMS collector for garbage collection. But we are seeing ParNew (promotion failed) due to fragmentation and ending up CMS having more than 30 seconds stop the world pauses every 12-13 hours. other than this normally CMS takes only 0.03 - 0.05 seconds of application pauses. Here is the JVM arguments we are using and the GC logs that has ParNew - promotion failed.
/opt/oracle/10gR3/jdk160_23/jre/bin/java -Dweblogic.Name=member3MS1 -Djava.security.policy=/opt/oracle/10gR3/wlserver_10.3/server/lib/weblogic.policy -Dweblogic.management.server=http://wdcsn443a.sys.cigna.com:7001 -Djava.library.path=/opt/oracle/10gR3/jdk160_23/jre/lib/sparc/client:/opt/oracle/10gR3/jdk160_23/jre/lib/sparc:/opt/oracle/10gR3/jdk160_23/jre/../lib/sparc:/opt/oracle/10gR3/patch_wlw1030/profiles/default/native:/opt/oracle/10gR3/patch_wls1030/profiles/default/native:/opt/oracle/10gR3/patch_cie670/profiles/default/native:/opt/oracle/10gR3/patch_aldsp1030/profiles/default/native:/opt/oracle/10gR3/patch_wlw1030/profiles/default/native:/opt/oracle/10gR3/patch_wls1030/profiles/default/native:/opt/oracle/10gR3/patch_cie670/profiles/default/native:/opt/oracle/10gR3/patch_aldsp1030/profiles/default/native:.:/opt/oracle/10gR3/wlserver_10.3/server/native/solaris/sparc:/opt/oracle/10gR3/wlserver_10.3/server/native/solaris/sparc/oci920_8:/opt/oracle/10gR3/wlserver_10.3/server/native/solaris/sparc:/opt/oracle/10gR3/wlserver_10.3/server/native/solaris/sparc/oci920_8:/opt/oracle/10gR3/wlserver_10.3/server/native/solaris/sparc:/opt/oracle/10gR3/wlserver_10.3/server/native/solaris/sparc/oci920_8:/usr/jdk/packages/lib/sparc:/lib:/usr/lib -Djava.class.path=/opt/oracle/10gR3/user_projects/lib/commons-lang-2.4.jar:/opt/oracle/10gR3/user_projects/lib/log4j-1.2.15.jar:/opt/oracle/10gR3/modules/com.bea.common.configfwk_1.2.0.0.jar:/opt/oracle/10gR3/modules/com.bea.core.xquery.beaxmlbeans-interop_1.3.0.0.jar:/opt/oracle/10gR3/modules/com.bea.core.xquery.xmlbeans-interop_1.3.0.0.jar:/opt/oracle/10gR3/modules/com.bea.core.binxml_1.3.0.0.jar:/opt/oracle/10gR3/modules/com.bea.core.sdo_1.1.0.0.jar:/opt/oracle/10gR3/modules/com.bea.core.xquery_1.3.0.0.jar:/opt/oracle/10gR3/modules/com.bea.alsb.client_1.1.0.0.jar:/opt/oracle/10gR3/modules/com.bea.common.configfwk.wlinterop_10.3.0.0.jar:/opt/oracle/10gR3/patch_wss110/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/opt/oracle/10gR3/patch_wls1001/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/opt/oracle/10gR3/patch_cie650/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/opt/oracle/10gR3/patch_aldsp320/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/opt/oracle/10gR3/jdk160_23/lib/tools.jar:/opt/oracle/10gR3/wlserver_10.3/server/lib/weblogic_sp.jar:/opt/oracle/10gR3/wlserver_10.3/server/lib/weblogic.jar:/opt/oracle/10gR3/modules/features/weblogic.server.modules_10.0.1.0.jar:/opt/oracle/10gR3/modules/features/com.bea.cie.common-plugin.launch_2.1.2.0.jar:/opt/oracle/10gR3/wlserver_10.3/server/lib/webservices.jar:/opt/oracle/10gR3/modules/org.apache.ant_1.6.5/lib/ant-all.jar:/opt/oracle/10gR3/modules/net.sf.antcontrib_1.0b2.0/lib/ant-contrib.jar:/opt/oracle/10gR3/modules/features/aldsp.server.modules_3.2.0.0.jar:/opt/oracle/10gR3/odsi_10.3/lib/ld-server-core.jar:/opt/oracle/10gR3/wlserver_10.3/common/eval/pointbase/lib/pbclient51.jar:/opt/oracle/10gR3/wlserver_10.3/server/lib/xqrl.jar:/opt/oracle/10gR3/user_projects/lib/db2jcc.jar:/opt/oracle/10gR3/user_projects/lib/db2jcc_license_cisuz.jar:/opt/oracle/10gR3/properties -Dweblogic.system.BootIdentityFile=/opt/oracle/10gR3/user_projects/domains/DataFabricDomain/servers/member3MS1/data/nodemanager/boot.properties -Dweblogic.nodemanager.ServiceEnabled=true -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.ReverseDNSAllowed=false -Xms2048m -Xmx2048m -Xmn640m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-UseBiasedLocking -XX:ParallelGCThreads=16 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -Xloggc:/logs/oracle/10gR3/DataFabricDomain/ManagedServer/member3agc.log_* -da -Dplatform.home=/opt/oracle/10gR3/wlserver_10.3 -Dwls.home=/opt/oracle/10gR3/wlserver_10.3/server -Dweblogic.home=/opt/oracle/10gR3/wlserver_10.3/server -Dwli.home=/opt/oracle/10gR3/wlserver_10.3/integration -Daldsp.home=/opt/oracle/10gR3/odsi_10.3 -Djavax.xml.soap.MessageFactory=weblogic.xml.saaj.MessageFactoryImpl -Dweblogic.management.discover=false -Dweblogic.management.server=http://wdcsn443a.sys.cigna.com:7001 -Dwlw.iterativeDev=false -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=true -Dweblogic.ext.dirs=/opt/oracle/10gR3/patch_wss110/profiles/default/sysext_manifest_classpath:/opt/oracle/10gR3/patch_wls1001/profiles/default/sysext_manifest_classpath:/opt/oracle/10gR3/patch_cie650/profiles/default/sysext_manifest_classpath:/opt/oracle/10gR3/patch_aldsp320/profiles/default/sysext_manifest_classpath -Dweblogic.system.BootIdentityFile=/opt/oracle/10gR3/user_projects/domains/DataFabricDomain/security/boot.properties -DDB2_USE_LEGACY_TOP_CLAUSE=true -Dlog4j.configuration=file:/opt/oracle/10gR3/user_projects/domains/DataFabricDomain/properties/log4j.xml -Ddeploymentsite=prod -DLOG4J_LEVEL=WARN -DLOG4J_ROOT=/logs/oracle/10gR3/DataFabricDomain -DLOG4J_NODENAME=member3a weblogic.Server
48461.245: [GC 48461.245: [*ParNew (promotion failed)*: 559017K->551408K(589824K), 1.1880458 secs]48462.433: [CMS: 1294242K->895754K(1441792K), 28.3698618 secs] 1852617K->895754K(2031616K), [CMS Perm : 122026K->120411K(262144K)], 29.5587684 secs] [Times: user=29.93 sys=0.04, real=29.56 secs]
Total time for which application threads were stopped: 29.5661221 seconds
109007.379: [GC 109007.380: [ParNew: 531521K->8922K(589824K), 0.0181922 secs] 1805634K->1283302K(2031616K), 0.0187539 secs] [Times: user=0.22 sys=0.01, real=0.02 secs]
Total time for which application threads were stopped: 0.0285263 seconds
Application time: 33.9224151 seconds
Total time for which application threads were stopped: 0.0086703 seconds
Application time: 8.5028806 seconds
109049.842: [GC 109049.842: [ParNew: 533210K->8861K(589824K), 0.0181380 secs] 1807590K->1283332K(2031616K), 0.0187288 secs] [Times: user=0.22 sys=0.01, real=0.02 secs]
Total time for which application threads were stopped: 0.0283473 seconds
Application time: 42.6375077 seconds
109092.508: [GC 109092.508: [ParNew: 533149K->8811K(589824K), 0.0161865 secs] 1807620K->1283418K(2031616K), 0.0167544 secs] [Times: user=0.19 sys=0.00, real=0.02 secs]
Total time for which application threads were stopped: 0.0264697 seconds
109122.582: [GC 109122.583: [*ParNew (promotion failed)*: 533099K->532822K(589824K), 1.2159460 secs]109123.799: [CMS: 1274986K->928935K(1441792K), 30.2900798 secs] 1807706K->928935K(2031616K), [CMS Perm : 127780K->126922K(262144K)], 31.5070045 secs] [Times: user=31.72 sys=0.04, real=31.51 secs]
Total time for which application threads were stopped: 31.5171276 seconds
Even though we cannot avoid fragmentation, what would be the best way to reduce these stop the world pauses?
Edited by: user12844507 on Mar 31, 2011 6:19 AM
Edited by: user12844507 on Mar 31, 2011 6:46 AM

The problem appears to be that the CMS work best if it can start before it is forced to start. The -XX:CMSInitiatingOccupancyFraction= determines at what point it should start before it is full. However it appear that this is too high, ie. you are creating objects too fast and it is running out of space before it finishes.
In particular you have "533099K->532822K(589824K)" which indicated to me you are filling the eden space with medium term lived objects very quickly. (More than 1/2 GB of them)
I would try to increase the young generation space until it appears to be too large. I would try "-XX:NewSize=2g -mx3g" to give it a much large younger generation space. This will stop some medium lived object being promopted and flooding the tenured space (which then have to be cleaned up and result in fragmentation)
Perhaps you have enough memory to try larger sizes. I use "-XX:NewSize=7g -mx8g" and I have no objects being prompted after startup.
BTW -mx == -Xmx
You might find this interesting http://blogs.sun.com/jonthecollector/entry/when_the_sum_of_the

Long GC pauses; full gc eventually takes 30 secs. (from Developer Forums)

from http://forum.java.sun.com/thread.jspa?threadID=5145522
jre 1.5.0_06,
-Dcom.sun.management.jmxremote -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:NewRatio=3 -XX:MaxTenuringThreshold=3 -XX:NewSize=90M -XX:MaxNewSize=90M -Xmx800M
windows 2003 server
normally, full gc's occur with < 1 second durations, but eventually, the duration peaks at 30 seconds, then 7 seconds, then back to normal
the heap was at about 290MB (far from full).
setting maxgcpausemillis has no effect (something extraordinary happens?)
there is no obvious pattern in the long pauses (not due to perm resizing or so)
does anyone have experience with sudden long pauses?
we could think of heap being swapped - but we don't know how to monitor this (and nobody was starting memory consuming applications at the time)
does anyone know how we best monitor swapping on a windows?
we are not able to use CMS immediately without testing for a period (had crashes due to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6386633)
here are samples of long pauses
here are some long pauses (days apart - the gc log is embedded in our own loggings)
061221 102753 0750 EV coreservice.taskoutput.container 75.537: [GC [PSYoungGen: 70133K->19827K(53632K)] 173056K->138149K(172736K), 11.5205585 secs] ##[
070301 122542 0812 EV coreservice.taskoutput.container 6146.116: [Full GC [PSYoungGen: 768K->0K(90944K)] [PSOldGen: 286976K->213826K(259328K)] 287744K->213826K(350272K) [PSPermGen: 19432K->19432K(23040K)], 30.1171480 secs] ##[
070305 163701 0140 EV coreservice.taskoutput.container [PSYoungGen: 1256K->0K(90176K)] [PSOldGen: 239309K->197132K(221632K)] 240565K->197132K(311808K) [PSPermGen: 19260K->19039K(23808K)], 20.3872070 secs] ##[
tak!
/aksel

does anyone know how we best monitor swapping on awindows?I not sure if this is the best.
You can use ctrl-shift-escape. Click on the processes tab and then goto the menu: View->Select Columns... and add "Page Fault Delta" column. I would also suggest you add the VM Memory size column too.

Long GC pause - grey object rescan

We observe occaisional GC pauses on our app server which seem to be caused by a "grey object rescan". In the past they ranged from 20-30s, but yesterday we had a 84s pause. That's a bit much...
[GC 1593754.769: [ParNew: 450212K->46400K(471872K), 0.1076340 secs] 1984347K->1585395K(3019584K), 0.1079070 secs]
1593757.147: [GC[YG occupancy: 339101 K (471872 K)]1593757.147: [Rescan (non-parallel) 1593757.147: [grey object rescan, 84.6104290
secs]1593841.758: [root rescan, 0.3187110 secs], 84.9293110 secs]1593842.076: [weak refs processing, 0.0100700 secs]1593842.087: [cl ass unloading, 0.1208600 secs]1593842.207: [scrub symbol & string tables, 0.0189270 secs] [1 CMS-remark: 1538995K(2547712K)] 1878096 K(3019584K), 85.1028700 secs]
My question is: what exactly causes this? Any way to avoid it?
I've found a couple bugs that might be related: 6367204, 6298694. Although I don't think there we have any huge arrays.
Or GC settings are as follows:
/usr/java/jdk1.5.0_06/bin/java -server -Xms3000m -Xmx3000m -XX:LargePageSizeInBytes=2m -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSCompactWhenClearAllSoftRefs -XX:SoftRefLRUPolicyMSPerMB=200 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=8 -XX:PermSize=156m -XX:MaxPermSize=156m -XX:CMSInitiatingOccupancyFraction=60 -Xloggc:/var/ec/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintClassHistogram -XX:+TraceClassUnloading -Duser.region=US -Dsun.rmi.dgc.client.gcInterval=86400000 -Dsun.rmi.dgc.server.gcInterval=86400000
Any help/suggestions are highly appreciated. Thanks!

When using the concurrent mark-sweep (cms) collector there is a phase where
cms is looking for all the live objects (referred to as concucrent marking of live objects)
in the heap while the application is running and likely changing objects in the heap.
In order to assure correctness cms has a phase (referred to as the remark)
where all the applications threads are stopped and it looks for
objects that have changed while it was doing the concurrent marking. The "grey object
rescan" refers to looking at the objects that have changed. This "grey object
rescan" depends on the number of objects that are changed during the
concurrent marking so the level of activity of the application can affect
this phase.
I note that you have turned off the parallel remark on the command line
(-XX:-CMSParallelRemarkEnabled). If you've had problems with the
parallel remark, then turning it on is not an option. If you have not had
problems with parallel remark, turn it on and see if it helps.
If you use the flag -XX:PrintCMSStatistics=1, you will get additional output.
In it you can look for lines such as
(re-scanned XXX dirty cards in cms gen)
If XXX is smaller in the cases where the "grey object rescan" is shorter and
XXX is larger in the cases where the "grey object rescan" is longer, then
the problem is due to lots of activity by the application during the concurrent
mark. If you're not on the 5.0 jdk and can move to it, please do. The parallel
remark will be more stable.

Long GC pauses; full gc eventually takes 30 seconds+

jre 1.5.0_06,
-Dcom.sun.management.jmxremote -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:NewRatio=3 -XX:MaxTenuringThreshold=3 -XX:NewSize=90M -XX:MaxNewSize=90M -Xmx800M
normally, full gc's occur with < 1 second durations, but eventually, the duration peaks at 30 seconds, then 7 seconds, then back to normal
the heap was at about 290MB (far from full).
setting maxgcpausemillis has no effect (something extraordinary happens?)
there is no obvious pattern in the long pauses (not due to perm resizing or so)
does anyone have experience with sudden long pauses?
we could think of heap being swapped - but we don't know how to monitor this (and nobody was starting memory consuming applications at the time)
tak!
/aksel

EDIT: Also I think NewSize/MaxNewSize should be set to the same value as NewRatio (fourth of the heap)yes - there is some confusion there.. the 90MB is used by the vm though
unfortunately we are not able to try out the cms immediately (as we are in production) - and even if this might be the end, we have to test the cms for a long time before entering production. we were hit by crashes caused by cms a year ago when we decided not to use it (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6386633)
here are some long pauses (days apart - the gc log is embedded in our own loggings)
061221 102753 0750 EV coreservice.taskoutput.container 75.537: [GC [PSYoungGen: 70133K->19827K(53632K)] 173056K->138149K(172736K), 11.5205585 secs] ##[
070301 122542 0812 EV coreservice.taskoutput.container 6146.116: [Full GC [PSYoungGen: 768K->0K(90944K)] [PSOldGen: 286976K->213826K(259328K)] 287744K->213826K(350272K) [PSPermGen: 19432K->19432K(23040K)], 30.1171480 secs] ##[
070305 163701 0140 EV coreservice.taskoutput.container [PSYoungGen: 1256K->0K(90176K)] [PSOldGen: 239309K->197132K(221632K)] 240565K->197132K(311808K) [PSPermGen: 19260K->19039K(23808K)], 20.3872070 secs] ##[

My old Apple Id can no longer be accessed due to my original e-mail being locked out. How can I switch Apple ID's without access to the one my phone continues to use?

My old hotmail account which has my old Apple ID (which is still connected to my phone) has been locked out. I have forgot the password to my original Apple ID and a recovery cannot be sent to my old account due to me not being locked out (believe someone has hacked it). I have set up a new Apple ID with a seperate e mail adress, however I cannot use the App Store because of my phone only recognizing the original e-mail I can no longer acess. Please help.

Contact the Apple account security team for your country and ask for assistance resetting the password: Apple ID: Contacting Apple for help with Apple ID account security.

Can no longer recommend Fascinate due to non-support of issues - class action time?

I loved my Fascinate when I got it, but the failure of Verizon to promptly resolve KNOWN software issues with known-to-Verizon solutions constitutes something dangerously close to fraud. Like others, I was promised a prompt upgrade to Froyo by a Verizon rep when I bought the phone. Like others. my GPS performance is terrible, with frequent delays of 10 minutes to infinity to achieve a location lock. Like others, I let my 30 day return expire because I was promised a software fix was coming out Real Soon Now, so now I am screwed.
The issue is NOT the delayed Froyo update,the issue is that the phone does not function as promised by Verizon when sold. Knowing sale of a defective product that does not meet its advertised features is fraudulent under the commercial code in any state of the union.
Therefore I am doing some of the few things I can do under the circumstances:
First of all, new buyers are warned that the phone DOES NOT WORK as advertised in many cases due to software issues with GPS, email push, and other features. If you buy it, don't expect it to work. If you are promised otherwise by a Verizon store or rep, be warned that the promises are empty. Be warned that the Verizon implementation of Bing en lieu of Google search and other disruptions of the base Google services makes the phone almost unusable compared to a true Android environment such as that on certain other Android phones and providers. Bing is terrible. VZNavigator is a rip off (and terrible). If you are a lawyer interested in a class action against Verizon related to thi sphone be aware that you should have plenty of interested parties. Personally I would like my service fees waved for the period from September when I bought the phone through whenever-they-actually-make-it-work with debugged software. It is clear that engineering KNOWS how to make the GPS work even without a full Froyo update - they just haven't released a patch.
I wish I could love this phone - but I can't recommend it any more to any one for any reason until Samsung/Verizon fix the software and de-Bing and de-bloat an otherwise excellent piece of hardware. This is EXACTLY what Apple got right, and that Verizon has wrong. A pox on them and their bloatware and BIng and broken search functions. It's like a bad dream. Swapping the hardware out for another Fasicinate won't fix it. I'm stuck.

Do I actually expect to see a suit? No, not really. But, message reads on the first page of the Fascinate forum suggest that as of now at least 4000 potential Fascinate owners may have received enough reasons to consider either a different phone or a different carrier. Verizon execs might have a look over the fence at IPhone land, where there is a mob wielding torches and pitch forks that loves their iPhones (but hates ATT for the poor service experience). Provide even average service and you build brand loyalty that overcomes almost any foul up. Give your customers good reasons to hate you, and they surely will.
Today I drove a 30 mile round trip with a fresh A-GPS almanac and never got GPS located closer than 1100 yards. If it ever DOES synch, it will be good to 10 ft. and stay locked until I go indoors. If. The Bluetooth refused to connect (again). Works great WHEN it actually occasionally works though. The hardware can do it. The software is a bad joke. Is is Samsung's fault? Maybe. Could Verizon provide a timely fix by internal or Samsung resources? Definitely. Samsung has fixed these issues for other markets long ago. The shame is that it takes what could be a great experience and sours it all. It's not about Froyo, it's about having basic features that work. While some of thse phones work perfectly, some combination of hardware and software issues means that too many customers did not receive what the paid for, and they have good reason to be angry with Verizon for the poor experience and callous treatment.

Long GC pauses due to 'wb processing'

Similar Messages

Maybe you are looking for