JDK-6289964 : Appserver 9 runs out of permspace when run in 64 bit mode.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0,5.0u5
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9,solaris_10
  • CPU: x86,sparc
  • Submitted: 2005-06-23
  • Updated: 2010-08-20
  • Resolved: 2010-08-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
JDK-6964458 - Reimplement class meta-data storage to use native memory
Relates :  
JDK-6309680 - hotspot "-d64" throwing Exception thread java.lang.OutOfMemoryError:Java heap space for sol10-b10AMD
Description
The Application server runs out of permanent generation space when running the Quicklook tests in 64 bit mode. The tests pass in 32 bit mode, but when started with the -d64 it throws the exception "java.lang.OutOfMemoryError: PermGen space", when running the Quicklook.

Logs are attached with +PrintHeapAtGC for Solaris9 and Solaris10 for both 32 bit and 64 bit runs. 


###@###.### 2005-06-23 15:52:46 GMT
Comments
EVALUATION This RFE has become somewhat obsolete (but not necessarily irrelevant) with time, in the sense that the data needed to affect any changes have changed substantially in the five years since this bug was filed. So I need to ask the submitter if this issue is still rerlevant, and whether there is any interest in pursuing this any further or not. Unfortunately, I cannot find either of the two submitters of this CR. I am therefore inclined to close this as a duplicate of another RFE, to which we refer the interested reader. If the original submitters somehow see this evaluation, they are welcome to reopen the RFE so that I may pursue it using new data should there be interest in that direction.
20-08-2010
SUGGESTED FIX Change the scaling factor for 64-bit for perm space sizing as needed, since "oop-richness"/"dilation factor" may be different from that of the regular heap.
20-08-2010
EVALUATION I examined the GC logs from the 32 bit and the (successful) 64 bit runs. Both indicate that the perm gen increases nearly monotnically over the course of the run. I am not sure if this is expected behaviour or if this constitutes a potential leak in the product. In any case, here is the relevant trace of perm gen occupancy: 32 bit: ======= 23.045: [Full GC 23.045: [Tenured: 5152K->4622K(6456K), 0.7423301 secs] 5618K->4622K(9656K), [Perm : 12287K->12195K(12288K)], 0.7427987 secs] 28.389: [Full GC 28.389: [Tenured: 5480K->5829K(7712K), 0.7313956 secs] 7544K->5829K(11552K), [Perm : 16383K->16383K(16384K)], 0.7321294 secs] 53.186: [Full GC 53.186: [Tenured: 9552K->9126K(14880K), 1.3106726 secs] 10121K->9126K(22240K), [Perm : 20479K->20479K(20480K)], 1.3110227 secs] 79.157: [Full GC 79.157: [Tenured: 12626K->12920K(20480K), 1.2857740 secs] 15681K->12920K(30592K), [Perm : 24573K->24573K(24576K)], 1.2861590 secs] 250.608: [Full GC 250.609: [Tenured: 43842K->38933K(44640K), 1.7964472 secs] 65010K->38933K(66464K), [Perm : 28671K->28671K(28672K)], 1.7982251 secs] 317.050: [Full GC 317.050: [Tenured: 40271K->40579K(59312K), 2.0379448 secs] 54015K->40579K(88368K), [Perm : 36607K->36607K(36608K)], 2.0392424 secs] 511.598: [Full GC 511.599: [Tenured: 55284K->43750K(67632K), 2.3175153 secs] 76313K->43750K(100720K), [Perm : 40703K->40703K(40704K)], 2.3186001 secs] 676.205: [Full GC 676.205: [Tenured: 63500K->48827K(72920K), 2.5672724 secs] 83162K->48827K(108568K), [Perm : 44799K->44799K(44800K)], 2.5685790 secs] 1078.341: [Full GC 1078.341: [Tenured: 91151K->54011K(96840K), 7.6173401 secs] 98755K->54011K(144072K), [Perm : 48895K->48895K(48896K)], 7.6180039 secs] 1137.955: [Full GC 1137.955: [Tenured: 88142K->53862K(96840K), 3.3691318 secs] 106285K->53862K(144072K), [Perm : 52991K->52991K(52992K)], 3.3697996 secs] 1639.216: [Full GC 1639.216: [Tenured: 101964K->61860K(118832K), 4.8995480 secs] 115785K->61860K(176752K), [Perm : 57087K->55018K(57088K)], 4.9002042 secs] 64-bit: ======= 51.109: [Tenured: 9245K->9493K(12872K), 1.1463226 secs] 14634K->9493K(19208K), [Perm : 26687K->26687K(26688K)] Heap after GC invocations=25: 56.804: [Tenured: 10368K->10658K(15824K), 0.9651955 secs] 13878K->10658K(23568K), [Perm : 32127K->32127K(32128K)] Heap after GC invocations=27: 64.069: [Tenured: 12369K->12444K(17768K), 1.0986827 secs] 13290K->12444K(26472K), [Perm : 37567K->37567K(37568K)] Heap after GC invocations=30: 121.546: [Tenured: 19318K->18084K(20744K), 2.3532030 secs] 25785K->18084K(30920K), [Perm : 43007K->42816K(43008K)] Heap after GC invocations=45: 158.104: [Tenured: 24146K->27365K(30144K), 1.7835452 secs] 35152K->27365K(44928K), [Perm : 48447K->48447K(48448K)] Heap after GC invocations=52: 489.973: [Tenured: 56057K->40201K(58488K), 2.3664659 secs] 78212K->40201K(86968K), [Perm : 59327K->59327K(59328K)] Heap after GC invocations=72: 497.991: [Tenured: 40201K->34945K(67008K), 3.0478874 secs] 51994K->34945K(99648K), [Perm : 64767K->64320K(64768K)] Heap after GC invocations=73: 833.961: [Tenured: 54373K->58201K(67008K), 3.2802940 secs] 75304K->58201K(99648K), [Perm : 70079K->70079K(70080K)] Heap after GC invocations=83: 1072.374: [Tenured: 86618K->50259K(97008K), 3.0886409 secs] 107884K->50259K(144176K), [Perm : 75519K->75519K(75520K)] Heap after GC invocations=93: 1120.836: [Tenured: 64853K->52232K(97008K), 3.1664251 secs] 87045K->52232K(144176K), [Perm : 80959K->80959K(80960K)] Heap after GC invocations=98: 1592.065: [Tenured: 85822K->55262K(117416K), 3.4917116 secs] 124746K->55262K(174504K), [Perm : 86399K->86399K(86400K)] Heap after GC invocations=124: 1654.009: [Tenured: 62613K->55920K(117416K), 3.4898959 secs] 90616K->55920K(174504K), [Perm : 91839K->91839K(91840K)] Heap after GC invocations=128: So looking at the last line of each trace, we have a normative dilation factor for the perm gen here of 91839K/55018K = 1.669. The corresponding number for the rest of the Java heap appears to be around 1.2 or so. This suggests that at least for this application there may be benefit from using a larger dilation factor for the perm gen default sizing. Data will be collected for other refworkload programs to get some more comparative samples to inform the sizing. This space will be updated with the collected data.
03-01-2008
EVALUATION For process reasons, this work is now officially targeted to Dolphin.
27-10-2005
EVALUATION The "dilation factor" factor 1.3 of the perm space for 64 bit jvm doesnt not seem to be adequate for the Appserver. ###@###.### 2005-06-23 15:52:47 GMT
23-06-2005