Memory Leak in Spawned JVM?
I have set up the Activatable RMI example form Sun and noticed something unusual while monitoring the Windows Task Manager.
When I run the client program for the first time two JVM's are spawned instead of one. When the client program finishes executing one JVM terminates while the other is left running. Everytime I execute the client program after that a new JVM is spawned and terminates (I assume this is the client program) while the other JVM grows by about 4-28k. Finally, when I terminate the rmi daemon the 'other' JVM terminates.
What is running in this 'other' JVM?
Why does it appear only after the first execution of the client program and not when the rmi daemon is started or when the setup program is run?
How can I terminate this JVM without killing the rmi daemon?
What is causing the memory leak?
Any ideas would be greatly apreciated, thanks.
Obviously the second JVM is for the Activatable object!
OK.
So when I run the client for the first time two JVM's are started one for the client program and one for the activatable object. When the client program finishes executing its JVM terminates. Meanwhile the activatable object's JVM still hangs around (and leaks memory).
I don't want this JVM to hang around too long. Ideally I would like to control how long an activatable object hangs around after the client is finished with it. Is there anyway to shutdown the activatable Objects JVM programatically?
Similar Messages
-
Memory leak in the JVM leading to system oom
Hi,
We are running application server using java 1.5, tomcat 5.5 ...
The problem is that the JVM is allocating memory continuously.
If we look at the JVM memory from JConsole everything is OK the amount of memory allocated in the heap does not grow significantly.
If we look at the JVM memory consumption from the system perspective, the memory usage is growing until the system runs out of memory and kill the JVM. The JVM memory usage goes beyong 1.5 Go of memory whatever options you use when launching the JVM.
The memory allocation is so intense that it can lead to a crash in few hours with very few users connected to the application.
We have tried JDK 1.5.05 and 1.5.06 still the same.
We are running on a Linux Debian system wth a 2.6.8 kernel.
Any idea of where all this memory goes ?
Any idea on how to track and solve this memory leak ?Hi Martinux,
Tiger and Mustang come with a number of diagnosing tools that could help
you spot memory problems. In particular there's something called 'jmap' which can
take a snapshot of the JVM memory.
Danny Coward has recently written a nice blog to emphasize the existence
of this new tools - see
"Crash Course: Java SE Monitoring, Management and Troubleshooting"
http://blogs.sun.com/roller/page/dannycoward?entry=crash_course_java_se_monitoring
Of course if the problem isn't in the JVM...
BTW: you did also look at the non-heap memory, right? and also at the total
number of loaded classes?
hope this helps,
-- daniel
JMX, SNMP, Java, etc...
http://blogs.sun.com/roller/page/jmxetc -
Huge memory leak in java jvm after update 2 for Snow leopard
Since I updated to Java Update 2 for Snow Leopard my JVM suddenly grows massive (10GB+ real memory - -Xmx=3500m) consuming all memory and rendering my iMac unusable. This does not happen predictably but does happen several times a day now requiring I power off and on again.
I had been living happily with update 1 with no such problem.
I need to either go back to update 1 (should have it on Time Machine) or find a solution for this problem.Our application is a j2ee-based commercial application facing to specified customers, having about 120 access request an hour.
We ' re doing stress test on the test server. The strange memory leak occurs at 1:20 am this morning while we're out of company , and no job was scheduled to run at that time. So I have the tendency to image that there is something inside oc4j had occured.
I have used OptimizeIt to monitor the heap status. However , as the memory leak problem occurs very occasionally ,and that tool deadly slows our server, we are currently using no profiling tools. -
What needs to be released to avoid memory leaks in the jvm?
I've got a C application server that makes Java calls to process requests.
Eventually, the JVM runs out of memory, I assume because my C code is leaking references.
My question is... what references should I be freeing? I am freeing local/global object references, but it still leaks memory.
Should I also be freeing classIds? Method ids? Is DeleteLocalRef() the way to do that?
Thanks,
JeffThe simple answer is that you are responsible for deallocating every single reference (basically anything that isn't either a fieldID or a methodID) that is returned from a JNI call. The return value from each JNI call is a newly allocated local reference that you must delete with a call to DeleteLocalRef. For example, you must delete the jclass returned by FindClass() or the jthrowable returned by ExceptionOccurred(). In addition to that, you must also ensure that you delete any global references that you explicitly allocate yourself.
Notice that the rules change, when you are executing from within the context of a native method invoked from the JVM. In that case, the JVM will automatically clean up any local references that are left over once the native method returns. Even then, though, it's smart to be careful with local references, because you can easily exceed the maximum number of local refs, or hold on to excessive amounts of objects, or hold onto objects for excessive amounts of time, because none of the local refs are deallocated by the VM until the native method actually returns.
Local reference management is a real pain in the butt in JNI. For example, it took me quite some time to get it right in Jace.
God bless,
-Toby Reyelts
Check out the free, open-source, JNI toolkit, Jace - http://jace.reyelts.com/jace -
Memory leak in jvm? totalMemory differs real memory usage
I working on a server application under linux with java 1.4.1_02.
The problem is that the OS reports after approx. 2 days a memory usage of about 200 MB while the JVM's totalMemory method says, that only about 20 MB are allocated and more than 10 MB of these 20 MB are free. Calling System.gc() doesn't help.
Is there a memory leak in the JVM itself ?
Is there a bugfix or workaround for preventing out of memory ?hi, here is some of the messages from our tomcat log. Please let us know if you see something here.
thanks
wh
14:04 Started Tomcat0.000: [GC 23352K->3056K(259264K), 0.0425550 secs]
6.396: [GC 26416K->3837K(259264K), 0.0428260 secs]
67.830: [GC 27197K->7675K(259264K), 0.0526750 secs]
14:11 Started OpenSTA load test (Tomcat 103M/103M SIZE/RSIZE)417.805: [Full GC 23900K->10468K(259264K), 0.1470690 secs]
464.368: [Full GC 29592K->12380K(259264K), 0.1984410 secs]
474.295: [GC 35740K->16076K(259264K), 0.0362230 secs]
482.470: [Full GC 32672K->16120K(259264K), 0.1574280 secs]
497.299: [Full GC 32266K->15347K(259264K), 0.1993480 secs]
513.132: [GC 38707K->15644K(259264K), 0.0067610 secs]
513.552: [Full GC 21105K->15833K(259264K), 0.1484350 secs]
524.393: [Full GC 31980K->15975K(259264K), 0.1507760 secs]
535.314: [Full GC 36832K->16164K(259264K), 0.1561530 secs]
544.704: [GC 39524K->16360K(259264K), 0.0035200 secs]
544.724: [Full GC 17439K->15435K(259264K), 0.1654420 secs]
550.837: [GC 38790K->15669K(259264K), 0.0031210 secs]
550.961: [Full GC 20198K->15612K(259264K), 0.1458520 secs]
561.816: [Full GC 36712K->15768K(259264K), 0.1535080 secs]
567.997: [Full GC 38928K->15944K(259264K), 0.1586890 secs]
572.313: [Full GC 29129K->15618K(259264K), 0.1764170 secs]
581.769: [Full GC 36749K->15768K(259264K), 0.1538980 secs]
588.514: [GC 39123K->16114K(259264K), 0.0042700 secs]
588.573: [Full GC 20576K->15878K(259264K), 0.1476950 secs]
592.833: [Full GC 34359K->16027K(259264K), 0.1563230 secs]
594.394: [GC 39387K->16189K(259264K), 0.0030660 secs]
596.453: [Full GC 30677K->15678K(259264K), 0.1698180 secs]
603.878: [GC 39038K->15839K(259264K), 0.0043830 secs]
610.088: [Full GC 32709K->15843K(259264K), 0.1554470 secs]
613.281: [Full GC 25096K->15932K(259264K), 0.1500100 secs]
618.982: [Full GC 35727K->16060K(259264K), 0.1558180 secs]
625.228: [Full GC 39090K->15677K(259264K), 0.1778470 secs]
638.611: [GC 39037K->15885K(259264K), 0.0034330 secs]
639.430: [Full GC 22116K->15866K(259264K), 0.1508080 secs]
646.904: [Full GC 26171K->16062K(259264K), 0.1532020 secs]
652.457: [Full GC 25748K->16156K(259264K), 0.1512670 secs]
658.609: [GC 39516K->16367K(259264K), 0.0032440 secs]
660.209: [Full GC 21359K->15677K(259264K), 0.1657590 secs]
664.911: [Full GC 34660K->15809K(259264K), 0.1562110 secs]
670.953: [Full GC 33108K->15937K(259264K), 0.1571950 secs]
673.849: [Full GC 29438K->16016K(259264K), 0.1531250 secs]
680.074: [GC 39376K->16523K(259264K), 0.0060770 secs]
680.279: [Full GC 26022K->15968K(259264K), 0.1805950 secs]
686.274: [Full GC 39141K->16092K(259264K), 0.1616190 secs]
688.844: [Full GC 36586K->16180K(259264K), 0.1567480 secs]
693.700: [Full GC 35574K->16344K(259264K), 0.1574960 secs]
700.598: [GC 39704K->16637K(259264K), 0.0035300 secs]
700.624: [Full GC 18174K->15872K(259264K), 0.1651170 secs]
703.509: [Full GC 34099K->16082K(259264K), 0.1573090 secs]
707.642: [GC 39442K->16171K(259264K), 0.0025780 secs]
709.815: [Full GC 28634K->16206K(259264K), 0.1534170 secs]
716.272: [Full GC 36047K->16381K(259264K), 0.1587900 secs]
723.495: [Full GC 39059K->16219K(259264K), 0.1683900 secs]
728.392: [GC 39577K->16618K(259264K), 0.0040680 secs]
728.415: [Full GC 18013K->16400K(259264K), 0.1536650 secs]
731.039: [Full GC 34082K->16531K(259264K), 0.1571980 secs]
737.472: [Full GC 32417K->16713K(259264K), 0.1577520 secs]
742.717: [Full GC 37469K->16111K(259264K), 0.1606780 secs]
744.274: [GC 39471K->16290K(259264K), 0.0033230 secs]
744.613: [Full GC 21102K->16265K(259264K), 0.1536350 secs]
748.395: [GC 39621K->16436K(259264K), 0.0031140 secs]
748.677: [Full GC 25242K->16359K(259264K), 0.1576130 secs]
750.854: [Full GC 31336K->16451K(259264K), 0.1585730 secs]
756.051: [Full GC 36466K->16119K(259264K), 0.1612460 secs]
759.115: [GC 39479K->16346K(259264K), 0.0028810 secs]
760.093: [Full GC 21902K->16228K(259264K), 0.1520320 secs]
763.760: [GC 39582K->16700K(259264K), 0.0059930 secs]
764.034: [Full GC 22526K->16387K(259264K), 0.1544760 secs]
768.679: [Full GC 32133K->16544K(259264K), 0.1591930 secs]
771.644: [Full GC 31230K->16325K(259264K), 0.1612140 secs]
776.770: [Full GC 38785K->16445K(259264K), 0.1620900 secs]
780.396: [Full GC 37938K->16896K(259264K), 0.1673300 secs]
782.776: [Full GC 30184K->17037K(259264K), 0.1590650 secs]
786.573: [GC 40397K->17228K(259264K), 0.0034880 secs]
786.731: [Full GC 19211K->16266K(259264K), 0.1549430 secs]
789.000: [GC 39619K->16361K(259264K), 0.0026020 secs]
789.269: [Full GC 19125K->16399K(259264K), 0.1513090 secs]
792.386: [Full GC 36010K->16508K(259264K), 0.1637400 secs]
795.102: [GC 39868K->16833K(259264K), 0.0040440 secs]
795.207: [Full GC 21389K->16739K(259264K), 0.1533440 secs]
799.324: [Full GC 23240K->16280K(259264K), 0.1577710 secs]
802.196: [GC 39639K->16518K(259264K), 0.0033770 secs]
802.399: [Full GC 22872K->16698K(259264K), 0.1572730 secs]
807.161: [GC 40058K->16776K(259264K), 0.0027580 secs]
809.900: [Full GC 36185K->16876K(259264K), 0.1607120 secs]
811.791: [Full GC 30282K->16978K(259264K), 0.1593370 secs]
813.563: [GC 40337K->17376K(259264K), 0.0064020 secs]
813.804: [Full GC 29057K->16982K(259264K), 0.1816130 secs]
815.297: [GC 40336K->17338K(259264K), 0.0039630 secs]
815.310: [Full GC 17806K->17082K(259264K), 0.1522910 secs]
819.516: [GC 40438K->17223K(259264K), 0.0028420 secs]
821.285: [Full GC 26923K->17272K(259264K), 0.1588350 secs]
823.559: [GC 40632K->17448K(259264K), 0.0031100 secs]
824.265: [Full GC 21492K->17462K(259264K), 0.1550870 secs]
825.397: [GC 40822K->17655K(259264K), 0.0031120 secs]
825.486: [Full GC 18871K->16337K(259264K), 0.1562730 secs]
829.469: [Full GC 38369K->16447K(259264K), 0.1650720 secs]
831.816: [GC 39807K->16601K(259264K), 0.0026710 secs]
831.827: [Full GC 17119K->16512K(259264K), 0.1522890 secs]
835.329: [GC 39872K->17080K(259264K), 0.0053700 secs]
835.465: [Full GC 23458K->16733K(259264K), 0.1581070 secs]
837.668: [GC 40093K->16935K(259264K), 0.0031290 secs]
838.251: [Full GC 20039K->16495K(259264K), 0.1564500 secs]
841.767: [Full GC 25895K->16613K(259264K), 0.1577470 secs]
844.476: [Full GC 35311K->16695K(259264K), 0.1628390 secs]
848.103: [GC 40044K->17069K(259264K), 0.0032710 secs]
848.628: [Full GC 22870K->16916K(259264K), 0.1580780 secs]
854.887: [Full GC 31905K->16323K(259264K), 0.1653390 secs]
857.228: [Full GC 36492K->16530K(259264K), 0.1634600 secs]
858.956: [GC 39890K->16815K(259264K), 0.0036330 secs]
862.023: [Full GC 21092K->16631K(259264K), 0.1564650 secs]
863.249: [Full GC 26164K->16781K(259264K), 0.1562600 secs]
865.711: [GC 40141K->17043K(259264K), 0.0031530 secs]
865.729: [Full GC 18180K->16457K(259264K), 0.1577410 secs]
869.627: [GC 39817K->16729K(259264K), 0.0033990 secs]
870.098: [Full GC 24966K->16659K(259264K), 0.1562460 secs]
872.350: [Full GC 31145K->16718K(259264K), 0.1604970 secs]
876.105: [Full GC 39279K->16941K(259264K), 0.1668260 secs]
880.207: [GC 40299K->17205K(259264K), 0.0034920 secs]
880.251: [Full GC 20652K->16517K(259264K), 0.1571090 secs]
883.114: [Full GC 37902K->16737K(259264K), 0.1646110 secs]
884.628: [Full GC 24661K->16849K(259264K), 0.1560830 secs]
888.022: [GC 40203K->17459K(259264K), 0.0051950 secs]
889.142: [Full GC 22380K->17051K(259264K), 0.1583020 secs]
891.554: [GC 40411K->17208K(259264K), 0.0027960 secs]
891.582: [Full GC 18063K->16781K(259264K), 0.1585470 secs]
892.405: [Full GC 29120K->17053K(259264K), 0.1622140 secs]
894.017: [GC 40406K->17464K(259264K), 0.0045690 secs]
895.447: [Full GC 31179K->17223K(259264K), 0.1628010 secs]
897.067: [Full GC 38729K->17329K(259264K), 0.1647360 secs]
900.396: [GC 40689K->17720K(259264K), 0.0044380 secs]
900.441: [Full GC 20648K->16903K(259264K), 0.1598090 secs]
902.678: [Full GC 35946K->17128K(259264K), 0.1663350 secs]
905.853: [GC 40488K->17532K(259264K), 0.0064380 secs]
905.891: [Full GC 19672K->17499K(259264K), 0.1621960 secs]
907.750: [GC 40847K->17670K(259264K), 0.0030520 secs]
908.460: [Full GC 20024K->17620K(259264K), 0.1565920 secs]
910.624: [GC 40980K->17765K(259264K), 0.0030090 secs]
910.671: [Full GC 18684K->16921K(259264K), 0.1605090 secs]
912.509: [Full GC 29066K->17017K(259264K), 0.1614450 secs]
913.757: [GC 40377K->17483K(259264K), 0.0047620 secs]
914.763: [Full GC 25902K->17141K(259264K), 0.1608170 secs]
917.689: [GC 40501K->17647K(259264K), 0.0049530 secs]
918.806: [Full GC 28871K->17294K(259264K), 0.1601960 secs]
921.558: [GC 40654K->17457K(259264K), 0.0029970 secs]
922.333: [Full GC 30464K->16925K(259264K), 0.1662820 secs]
923.373: [GC 40285K->17159K(259264K), 0.0042550 secs]
923.555: [Full GC 24496K->17082K(259264K), 0.1599500 secs]
927.044: [Full GC 37046K->17226K(259264K), 0.1683760 secs]
929.061: [GC 40586K->17346K(259264K), 0.0026490 secs]
929.162: [Full GC 21815K->17310K(259264K), 0.1590250 secs]
931.978: [GC 40670K->17413K(259264K), 0.0024780 secs]
932.513: [Full GC 23342K->16981K(259264K), 0.1626270 secs]
935.043: [GC 40341K->17151K(259264K), 0.0028210 secs]
935.520: [Full GC 29674K->17213K(259264K), 0.1660230 secs]
937.492: [GC 40573K->17558K(259264K), 0.0039620 secs]
937.670: [Full GC 23593K->17320K(259264K), 0.1597560 secs]
938.607: [GC 40680K->17648K(259264K), 0.0045610 secs]
939.678: [Full GC 33877K->17515K(259264K), 0.1648540 secs]
942.806: [GC 40869K->18021K(259264K), 0.0051340 secs]
944.254: [Full GC 35743K->17147K(259264K), 0.1719980 secs]
945.155: [Full GC 36250K->17530K(259264K), 0.1705550 secs]
946.222: [Full GC 34120K->17623K(259264K), 0.1649620 secs]
949.645: [Full GC 30572K->17807K(259264K), 0.1649170 secs]
952.442: [GC 41163K->17964K(259264K), 0.0030280 secs]
952.566: [Full GC 20289K->16895K(259264K), 0.1610340 secs]
954.853: [Full GC 28279K->17090K(259264K), 0.1638610 secs]
957.884: [GC 40445K->17584K(259264K), 0.0047550 secs]
958.667: [Full GC 32363K->17427K(259264K), 0.1661990 secs]
959.881: [Full GC 33152K->17499K(259264K), 0.1664660 secs]
964.265: [Full GC 37131K->17078K(259264K), 0.1695560 secs]
967.544: [Full GC 39971K->17286K(259264K), 0.1698470 secs]
972.467: [GC 40645K->17716K(259264K), 0.0058330 secs]
972.573: [Full GC 19899K->17688K(259264K), 0.1596110 secs]
973.323: [GC 41048K->18078K(259264K), 0.0039180 secs]
973.767: [Full GC 30629K->18056K(259264K), 0.1642740 secs]
975.978: [Full GC 32502K->16772K(259264K), 0.1692030 secs]
977.636: [GC 40132K->17237K(259264K), 0.0055500 secs]
978.935: [Full GC 25669K->16985K(259264K), 0.1628640 secs]
980.311: [Full GC 36664K->17060K(259264K), 0.1661300 secs]
984.254: [GC 40420K->17283K(259264K), 0.0035880 secs]
984.947: [Full GC 28397K->17339K(259264K), 0.1645970 secs]
988.111: [Full GC 30208K->16821K(259264K), 0.1669820 secs]
991.456: [Full GC 24124K->16941K(259264K), 0.1607770 secs]
994.575: [GC 40301K->17145K(259264K), 0.0035460 secs]
995.050: [Full GC 26065K->17242K(259264K), 0.1658660 secs]
996.625: [Full GC 37922K->17434K(259264K), 0.1697800 secs]
999.246: [Full GC 31259K->17049K(259264K), 0.1676220 secs]
1001.492: [GC 40408K->17779K(259264K), 0.0078300 secs]
1001.859: [Full GC 34893K->17307K(259264K), 0.1669200 secs]
1004.393: [GC 40666K->17525K(259264K), 0.0030640 secs]
1004.425: [Full GC 20060K->17436K(259264K), 0.1593370 secs]
1007.645: [GC 40794K->17669K(259264K), 0.0030540 secs]
1008.124: [Full GC 30847K->17795K(259264K), 0.1688060 secs]
1009.680: [Full GC 27073K->17588K(259264K), 0.1798900 secs]
1011.538: [Full GC 30414K->17677K(259264K), 0.1661910 secs]
1016.696: [GC 41037K->17878K(259264K), 0.0043140 secs]
1017.675: [GC 41238K->18305K(259264K), 0.0076230 secs]
1017.697: [Full GC 18965K->17980K(259264K), 0.1633270 secs]
1018.701: [Full GC 40089K->18034K(259264K), 0.1699260 secs]
1022.387: [Full GC 40085K->17215K(259264K), 0.1718460 secs]
1024.329: [GC 40575K->17390K(259264K), 0.0033200 secs]
1025.327: [Full GC 32127K->17405K(259264K), 0.1646980 secs]
1027.948: [GC 40765K->18028K(259264K), 0.0072570 secs]
1028.257: [Full GC 33726K->17576K(259264K), 0.1646440 secs]
1029.759: [Full GC 35673K->17688K(259264K), 0.1722710 secs]
1032.229: [Full GC 29552K->17224K(259264K), 0.1670930 secs]
1036.764: [GC 40584K->17488K(259264K), 0.0044870 secs]
1037.789: [Full GC 23532K->17375K(259264K), 0.1604060 secs]
1040.193: [Full GC 40682K->17543K(259264K), 0.1722250 secs]
1041.362: [GC 40902K->17948K(259264K), 0.0044240 secs]
1042.386: [Full GC 29926K->17651K(259264K), 0.1651240 secs]
1046.173: [GC 41011K->17786K(259264K), 0.0030940 secs]
1046.186: [Full GC 18169K->17442K(259264K), 0.1657440 secs]
1048.882: [GC 40802K->17670K(259264K), 0.0032420 secs]
1049.728: [Full GC 26921K->17623K(259264K), 0.1666840 secs]
1050.667: [Full GC 27281K->17714K(259264K), 0.1655080 secs]
1053.205: [Full GC 39795K->17784K(259264K), 0.1699730 secs]
1055.242: [Full GC 37892K->17524K(259264K), 0.1736060 secs]
1058.278: [GC 40877K->17783K(259264K), 0.0032240 secs]
1058.934: [Full GC 24636K->17670K(259264K), 0.1629560 secs]
1061.572: [Full GC 32462K->17738K(259264K), 0.1658050 secs]
1064.860: [GC 41090K->18049K(259264K), 0.0031520 secs]
1064.873: [Full GC 18402K->17913K(259264K), 0.1598100 secs]
1068.969: [GC 41272K->18129K(259264K), 0.0030650 secs]
1069.415: [Full GC 25714K->17421K(259264K), 0.1689390 secs]
1070.981: [Full GC 40072K->17529K(259264K), 0.1719780 secs]
1072.694: [Full GC 40298K->17684K(259264K), 0.1755570 secs]
1074.349: [Full GC 29692K->17760K(259264K), 0.1646700 secs]
1079.137: [GC 41120K->18001K(259264K), 0.0032570 secs]
1079.901: [Full GC 29267K->17912K(259264K), 0.1952200 secs]
1081.705: [GC 41272K->18459K(259264K), 0.0059700 secs]
1082.812: [Full GC 28652K->18115K(259264K), 0.1686030 secs]
1084.535: [GC 41475K->18286K(259264K), 0.0029690 secs]
1085.759: [Full GC 22825K->18304K(259264K), 0.1620300 secs]
1088.874: [GC 41664K->18557K(259264K), 0.0032180 secs]
1090.304: [Full GC 23507K->18428K(259264K), 0.1613190 secs]
1092.560: [GC 41787K->18731K(259264K), 0.0037290 secs]
1092.568: [Full GC 18918K->17280K(259264K), 0.1863890 secs]
1094.698: [Full GC 40048K->17487K(259264K), 0.1717440 secs]
1097.608: [GC 40847K->17639K(259264K), 0.0029460 secs]
1097.770: [Full GC 21453K->17546K(259264K), 0.1593820 secs]
1101.222: [Full GC 34584K->17699K(259264K), 0.1714350 secs]
1103.842: [Full GC 29518K->17398K(259264K), 0.1673060 secs]
1105.429: [Full GC 36543K->17480K(259264K), 0.1687430 secs]
1107.633: [GC 40839K->17863K(259264K), 0.0037960 secs]
1109.418: [Full GC 38489K->17844K(259264K), 0.1714760 secs]
1110.644: [GC 41201K->18176K(259264K), 0.0037780 secs]
1110.708: [Full GC 22032K->18031K(259264K), 0.1629450 secs]
1112.769: [Full GC 33242K->17641K(259264K), 0.1746310 secs]
1115.871: [GC 41001K->17913K(259264K), 0.0042400 secs]
1115.936: [Full GC 18849K->17868K(259264K), 0.1649840 secs]
1116.903: [GC 41228K->18158K(259264K), 0.0038590 secs]
1117.142: [Full GC 23635K->18147K(259264K), 0.1661090 secs]
1119.657: [Full GC 33873K->18237K(259264K), 0.1687550 secs]
1122.138: [GC 41597K->18843K(259264K), 0.0057360 secs]
1122.460: [Full GC 30191K->17352K(259264K), 0.1718040 secs]
1124.176: [GC 40711K->17534K(259264K), 0.0032200 secs]
1124.188: [Full GC 18088K->17408K(259264K), 0.1585710 secs]
1126.471: [GC 40768K->17610K(259264K), 0.0030090 secs]
1126.621: [Full GC 23207K->17585K(259264K), 0.1639700 secs]
1130.601: [GC 40945K->18032K(259264K), 0.0057690 secs]
1130.987: [Full GC 33251K->17715K(259264K), 0.1698070 secs]
1132.400: [GC 41075K->18200K(259264K), 0.0048990 secs]
1133.852: [Full GC 22412K->17396K(259264K), 0.1678410 secs]
1134.988: [GC 40756K->17811K(259264K), 0.0047240 secs]
1135.108: [Full GC 22610K->17538K(259264K), 0.1632820 secs]
1138.140: [Full GC 35484K->17677K(259264K), 0.1697280 secs]
1140.949: [GC 41037K->18028K(259264K), 0.0039610 secs]
1142.579: [Full GC 26182K->17886K(259264K), 0.1663820 secs]
1145.332: [Full GC 38186K->17413K(259264K), 0.1775910 secs]
1147.998: [Full GC 31086K->17542K(259264K), 0.1694310 secs]
1150.183: [GC 40902K->17680K(259264K), 0.0028430 secs]
1151.988: [Full GC 23320K->17714K(259264K), 0.1662670 secs]
1153.556: [GC 41074K->18019K(259264K), 0.0033240 secs]
1153.694: [Full GC 22297K->17819K(259264K), 0.1636210 secs]
1156.910: [Full GC 32491K->17555K(259264K), 0.1708090 secs]
1159.295: [GC 40915K->17925K(259264K), 0.0041940 secs]
1159.584: [Full GC 27356K->17749K(259264K), 0.1684860 secs]
1162.179: [Full GC 40840K->17842K(259264K), 0.1709320 secs]
1165.462: [Full GC 40836K->17998K(259264K), 0.1745900 secs]
1169.213: [Full GC 38228K->17387K(259264K), 0.1773150 secs]
1173.839: [Full GC 38730K->17553K(259264K), 0.1721990 secs]
1176.118: [Full GC 28517K->17724K(259264K), 0.1694920 secs]
1178.427: [GC 41084K->18236K(259264K), 0.0056840 secs]
1178.476: [Full GC 21916K->17907K(259264K), 0.1636330 secs]
1180.035: [Full GC 28804K->17629K(259264K), 0.1706580 secs]
1183.111: [GC 40989K->17821K(259264K), 0.0039230 secs]
1183.470: [Full GC 27647K->17770K(259264K), 0.1642930 secs]
1186.098: [Full GC 34782K->18020K(259264K), 0.1711540 secs]
1189.374: [GC 41380K->18148K(259264K), 0.0030680 secs]
1189.773: [Full GC 19108K->18108K(259264K), 0.1620400 secs]
1193.545: [GC 41468K->18264K(259264K), 0.0030810 secs]
1195.049: [Full GC 33109K->17520K(259264K), 0.1722670 secs]
1197.419: [Full GC 34615K->17775K(259264K), 0.1743520 secs]
1198.468: [Full GC 27126K->17819K(259264K), 0.1658660 secs]
1201.775: [GC 41179K->18064K(259264K), 0.0032670 secs]
1202.434: [Full GC 34303K->18285K(259264K), 0.1741190 secs]
1204.504: [GC 41645K->18591K(259264K), 0.0040820 secs]
1205.473: [Full GC 28617K->17816K(259264K), 0.1725460 secs]
1206.615: [Full GC 23644K->17914K(259264K), 0.1654130 secs]
1208.603: [GC 41274K->18294K(259264K), 0.0047020 secs]
1208.659: [Full GC 21617K->18046K(259264K), 0.1671710 secs]
1210.184: [Full GC 38308K->18107K(259264K), 0.1723240 secs]
1212.135: [Full GC 26647K->17955K(259264K), 0.1731150 secs]
1216.077: [GC 41314K->18170K(259264K), 0.0041080 secs]
1216.475: [Full GC 28069K->18058K(259264K), 0.1722190 secs]
1218.160: [GC 41418K->18256K(259264K), 0.0029660 secs]
1218.196: [Full GC 19422K->18244K(259264K), 0.1601460 secs]
1220.002: [Full GC 26298K->18354K(259264K), 0.1672780 secs]
1222.871: [Full GC 41007K->17486K(259264K), 0.1767970 secs]
1224.257: [Full GC 38459K->17581K(259264K), 0.1708260 secs]
1228.508: [Full GC 31027K->17678K(259264K), 0.1934270 secs]
1230.842: [GC 41038K->17846K(259264K), 0.0027980 secs]
1231.091: [Full GC 23773K->17876K(259264K), 0.1648090 secs]
1233.377: [GC 41235K->18030K(259264K), 0.0043450 secs]
1234.627: [Full GC 27018K->17623K(259264K), 0.1681140 secs]
1238.083: [GC 40983K->18145K(259264K), 0.0053580 secs]
1238.236: [Full GC 26915K->17828K(259264K), 0.1658790 secs]
1240.558: [Full GC 32151K->17956K(259264K), 0.1687010 secs]
1243.685: [GC 41310K->18474K(259264K), 0.0058920 secs]
1246.029: [Full GC 41795K->18533K(259264K), 0.1784250 secs]
1249.400: [GC 41893K->18739K(259264K), 0.0035550 secs]
1249.741: [Full GC 22503K->17989K(259264K), 0.1702740 secs]
1252.402: [GC 41347K->18176K(259264K), 0.0039630 secs]
1252.516: [Full GC 20445K->18258K(259264K), 0.1678890 secs]
1254.473: [Full GC 37435K->18439K(259264K), 0.1891770 secs]
1257.912: [GC 41797K->18658K(259264K), 0.0034350 secs]
1258.627: [Full GC 28099K->18792K(259264K), 0.1701140 secs]
1259.558: [GC 42151K->19185K(259264K), 0.0040460 secs]
1259.685: [Full GC 24326K->17830K(259264K), 0.1797960 secs]
1261.675: [Full GC 35858K->17895K(259264K), 0.1747070 secs]
1265.409: [GC 41253K->18235K(259264K), 0.0045390 secs]
1265.480: [Full GC 21386K->18167K(259264K), 0.1647190 secs]
1266.987: [GC 41527K->18518K(259264K), 0.0042120 secs]
1267.097: [Full GC 23121K->18225K(259264K), 0.1638840 secs]
1269.256: [GC 41579K->18556K(259264K), 0.0034600 secs]
1269.907: [Full GC 25021K->17589K(259264K), 0.1682260 secs]
1272.214: [Full GC 29448K->17641K(259264K), 0.1673120 secs]
1274.376: [Full GC 32613K->17885K(259264K), 0.1710000 secs]
1278.034: [GC 41245K->18309K(259264K), 0.0044890 secs]
1278.139: [Full GC 20559K->18359K(259264K), 0.1699630 secs]
1281.824: [GC 41719K->18836K(259264K), 0.0042590 secs]
1281.869: [Full GC 22173K->17938K(259264K), 0.1710780 secs]
1282.883: [Full GC 38905K->18085K(259264K), 0.1729570 secs]
1285.470: [Full GC 29364K->18221K(259264K), 0.1712110 secs]
1287.186: [GC 41579K->18392K(259264K), 0.0037710 secs]
1287.648: [Full GC 34833K->18379K(259264K), 0.1722590 secs]
1293.044: [Full GC 36896K->17895K(259264K), 0.1790080 secs]
1295.344: [Full GC 39122K->17997K(259264K), 0.1739800 secs]
1298.695: [GC 41356K->18180K(259264K), 0.0035400 secs]
1299.139: [Full GC 27101K->18151K(259264K), 0.1662500 secs]
1301.236: [Full GC 29897K->18243K(259264K), 0.1670530 secs]
1304.222: [GC 41599K->18690K(259264K), 0.0051650 secs]
1304.631: [Full GC 26785K->17570K(259264K), 0.1685990 secs]
1307.040: [Full GC 35984K->17736K(259264K), 0.1714940 secs]
1308.610: [Full GC 33194K->17867K(259264K), 0.1732130 secs]
1310.245: [GC 41227K->18348K(259264K), 0.0046460 secs]
1310.270: [Full GC 20079K->17997K(259264K), 0.1622390 secs]
1316.119: [Full GC 31797K->17701K(259264K), 0.1767490 secs]
1317.765: [GC 41061K->17911K(259264K), 0.0034320 secs]
1318.459: [Full GC 36597K->18147K(259264K), 0.1772120 secs]
1319.623: [Full GC 32165K->18210K(259264K), 0.1702940 secs]
1323.339: [GC 41570K->18394K(259264K), 0.0035930 secs]
1323.362: [Full GC 20003K->18302K(259264K), 0.1621850 secs]
1328.455: [GC 41662K->18528K(259264K), 0.0031090 secs]
1329.080: [Full GC 26141K->17601K(259264K), 0.1714570 secs]
1330.502: [GC 40960K->18190K(259264K), 0.0055370 secs]
1331.248: [Full GC 33207K->17743K(259264K), 0.1716600 secs]
1332.504: [Full GC 33325K->17919K(259264K), 0.1707440 secs]
1334.322: [Full GC 25962K->17964K(259264K), 0.1647600 secs]
1339.043: [GC 41324K->18445K(259264K), 0.0053560 secs]
1339.431: [Full GC 30802K->18036K(259264K), 0.1760700 secs]
1340.706: [GC 41396K->18435K(259264K), 0.0049790 secs]
1340.788: [Full GC 19653K->18362K(259264K), 0.1679480 secs]
1341.402: [Full GC 37930K->18541K(259264K), 0.1789520 secs]
1343.397: [Full GC 38599K->18598K(259264K), 0.1745700 secs]
1345.654: [Full GC 38131K->17863K(259264K), 0.1768640 secs]
1349.079: [Full GC 40810K->18034K(259264K), 0.1751080 secs]
1351.329: [GC 41394K->18181K(259264K), 0.0031310 secs]
1351.630: [Full GC 22737K->18131K(259264K), 0.1667750 secs]
1353.752: [GC 41491K->18415K(259264K), 0.0039180 secs]
1353.771: [Full GC 19663K->18329K(259264K), 0.1658580 secs]
1356.021: [Full GC 33020K->17962K(259264K), 0.1772410 secs]
1362.446: [GC 41322K->18319K(259264K), 0.0041650 secs]
1362.707: [Full GC 28140K->18280K(259264K), 0.1717800 secs]
1364.104: [GC 41640K->18440K(259264K), 0.0035700 secs]
1364.219: [Full GC 19931K->18444K(259264K), 0.1673940 secs]
1367.044: [Full GC 41175K->18638K(259264K), 0.1774620 secs]
1369.008: [GC 41998K->18904K(259264K), 0.0033770 secs]
1370.808: [Full GC 39500K->17736K(259264K), 0.1779480 secs]
1372.395: [Full GC 38579K->17798K(259264K), 0.1732010 secs]
1374.965: [GC 41158K->17977K(259264K), 0.0032530 secs]
1375.530: [Full GC 32640K->18465K(259264K), 0.1768610 secs]
1376.498: [Full GC 37663K->18530K(259264K), 0.1755930 secs]
1379.187: [Full GC 34360K->17772K(259264K), 0.1767890 secs]
1381.635: [GC 41132K->17916K(259264K), 0.0030470 secs]
1382.740: [Full GC 33087K->17979K(259264K), 0.1725710 secs]
1384.342: [Full GC 40704K->18127K(259264K), 0.1782130 secs]
1386.079: [Full GC 37351K->18238K(259264K), 0.1749410 secs]
1388.360: [Full GC 37386K->17696K(259264K), 0.1768570 secs]
1390.025: [Full GC 29469K->17756K(259264K), 0.1694570 secs]
1393.734: [GC 41112K->18057K(259264K), 0.0038490 secs]
1394.247: [Full GC 26711K->17971K(259264K), 0.1697510 secs]
1395.559: [GC 41331K->18421K(259264K), 0.0046160 secs]
1395.724: [Full GC 22935K->18369K(259264K), 0.1683440 secs]
1399.015: [GC 41729K->18557K(259264K), 0.0031830 secs]
1400.459: [Full GC 24074K->17934K(259264K), 0.1763530 secs]
1403.708: [GC 41285K->18399K(259264K), 0.0047150 secs]
1403.906: [Full GC 26160K->18149K(259264K), 0.1707510 secs]
1406.124: [GC 41509K->18387K(259264K), 0.0035380 secs]
1406.848: [Full GC 29898K->18662K(259264K), 0.1756120 secs]
1407.882: [Full GC 36353K->18762K(259264K), 0.1732850 secs]
1409.476: [Full GC 31392K->18111K(259264K), 0.1766410 secs]
1413.341: [GC 41471K->18259K(259264K), 0.0029240 secs]
1414.016: [Full GC 23700K->18347K(259264K), 0.1689310 secs]
1416.973: [GC 41707K->18621K(259264K), 0.0032220 secs]
1417.033: [Full GC 21370K->18493K(259264K), 0.1729750 secs]
1418.844: [Full GC 41535K->18652K(259264K), 0.1788500 secs]
1421.566: [Full GC 37085K->17599K(259264K), 0.1771590 secs]
1426.447: [Full GC 39674K->17772K(259264K), 0.1779320 secs]
1427.655: [Full GC 34052K->17910K(259264K), 0.1752830 secs]
1428.736: [Full GC 31329K->18038K(259264K), 0.1709880 secs]
1431.035: [GC 41398K->18234K(259264K), 0.0033650 secs]
1431.545: [Full GC 32607K->17774K(259264K), 0.1744760 secs]
1435.344: [Full GC 35392K->17901K(259264K), 0.1731200 secs]
1440.290: [Full GC 39635K->18103K(259264K), 0.1759120 secs]
1443.216: [GC 41463K->18459K(259264K), 0.0039860 secs]
1443.627: [Full GC 28455K->18606K(259264K), 0.1717400 secs]
1446.677: [Full GC 31845K->17807K(259264K), 0.1757170 secs]
1448.217: [Full GC 36029K->17929K(259264K), 0.1723040 secs]
1451.897: [Full GC 40425K->18068K(259264K), 0.1773810 secs]
1453.303: [GC 41428K->18399K(259264K), 0.0043310 secs]
1454.383: [GC 41747K->18891K(259264K), 0.0066130 secs]
1454.603: [Full GC 26649K->18470K(259264K), 0.1726960 secs]
1455.862: [GC 41830K->19071K(259264K), 0.0057860 secs]
1455.919: [Full GC 23860K->18080K(259264K), 0.1716680 secs]
1459.396: [GC 41440K->18551K(259264K), 0.0048670 secs]
1459.560: [Full GC 21678K->18433K(259264K), 0.1685140 secs]
1460.305: [Full GC 28004K->18540K(259264K), 0.1708560 secs]
1463.360: [GC 41898K->19157K(259264K), 0.0053660 secs]
1463.385: [Full GC 19875K->18963K(259264K), 0.1695990 secs]
1465.299: [GC 42322K->19230K(259264K), 0.0037680 secs]
1466.243: [Full GC 30800K->18146K(259264K), 0.2014600 secs]
1468.739: [GC 41506K->18435K(259264K), 0.0042590 secs]
1469.240: [Full GC 23481K->18360K(259264K), 0.1682010 secs]
1470.849: [Full GC 37140K->18509K(259264K), 0.1753980 secs]
1473.283: [Full GC 28643K->18566K(259264K), 0.1716950 secs]
1475.513: [GC 41926K->18655K(259264K), 0.0024490 secs]
1476.303: [Full GC 28013K->17893K(259264K), 0.1730760 secs]
1479.100: [GC 41253K->18106K(259264K), 0.0032820 secs]
1479.114: [Full GC 19042K->18011K(259264K), 0.1668360 secs]
1480.705: [GC 41371K->18216K(259264K), 0.0033410 secs]
1480.820: [Full GC 21912K->18126K(259264K), 0.1680140 secs]
1483.212: [GC 41483K->18657K(259264K), 0.0068210 secs]
1483.612: [Full GC 32191K->18531K(259264K), 0.1748200 secs]
1484.237: [Full GC 27101K->17945K(259264K), 0.1720220 secs]
1487.355: [GC 41304K->18052K(259264K), 0.0028180 secs]
1487.453: [Full GC 18350K->18034K(259264K), 0.1671100 secs]
1491.399: [Full GC 30457K->18216K(259264K), 0.1750190 secs]
1493.152: [GC 41576K->18373K(259264K), 0.0030600 secs]
1495.040: [Full GC 35834K->18553K(259264K), 0.1844910 secs]
1496.486: [Full GC 40056K->18404K(259264K), 0.1839830 secs]
1497.604: [Full GC 40636K->18576K(259264K), 0.1802690 secs]
1499.708: [Full GC 32806K->18699K(259264K), 0.1755440 secs]
1502.358: [GC 42056K->19017K(259264K), 0.0035950 secs]
1503.448: [Full GC 39416K->19186K(259264K), 0.1810510 secs]
1504.321: [GC 42546K->19502K(259264K), 0.0041760 secs]
1504.523: [Full GC 26135K->18075K(259264K), 0.1737100 secs]
1506.421: [Full GC 34630K->18190K(259264K), 0.1749040 secs]
1509.521: [Full GC 34218K->18280K(259264K), 0.1738500 secs]
1512.404: [Full GC 40123K->18419K(259264K), 0.1785160 secs]
1514.910: [GC 41779K->18978K(259264K), 0.0046400 secs]
1515.057: [Full GC 21217K->18346K(259264K), 0.1729520 secs]
1516.312: [Full GC 32009K->18445K(259264K), 0.1742600 secs]
1519.535: [GC 41800K->18681K(259264K), 0.0033170 secs]
1521.938: [Full GC 39950K->18817K(259264K), 0.1806540 secs]
1522.918: [Full GC 39996K->18896K(259264K), 0.1770260 secs]
1525.240: [Full GC 27208K->18087K(259264K), 0.1766390 secs]
1527.746: [GC 41446K->18283K(259264K), 0.0030650 secs]
1529.193: [Full GC 31590K->18230K(259264K), 0.1739110 secs]
1531.467: [GC 41590K->18408K(259264K), 0.0031390 secs]
1531.621: [Full GC 20536K->18343K(259264K), 0.1684640 secs]
1534.052: [Full GC 39614K->18673K(259264K), 0.1790600 secs]
1536.308: [Full GC 41947K->18277K(259264K), 0.1831870 secs]
1540.110: [GC 41634K->18676K(259264K), 0.0037740 secs]
1540.655: [Full GC 22982K->18554K(259264K), 0.1718110 secs]
1543.403: [Full GC 40455K->18762K(259264K), 0.1808010 secs]
1544.456: [GC 42122K->19049K(259264K), 0.0056720 secs]
1544.623: [Full GC 24100K->19040K(259264K), 0.1734450 secs]
1547.598: [GC 42399K->19313K(259264K), 0.0031750 secs]
1547.782: [Full GC 21803K->17896K(259264K), 0.1733430 secs]
1550.856: [Full GC 38776K->18049K(259264K), 0.1790000 secs]
1554.027: [Full GC 39925K->18209K(259264K), 0.1794380 secs]
1554.868: [Full GC 36385K->18297K(259264K), 0.1765220 secs]
1557.076: [GC 41657K->18481K(259264K), 0.0033910 secs]
1557.170: [Full GC 23085K->17844K(259264K), 0.1733090 secs]
1558.265: [Full GC 21638K->17878K(259264K), 0.1694620 secs]
1563.060: [GC 41237K->18097K(259264K), 0.0033500 secs]
1564.856: [Full GC 32663K->18154K(259264K), 0.1754150 secs]
1566.025: [GC 41510K->18340K(259264K), 0.0031060 secs]
1566.042: [Full GC 19331K->18242K(259264K), 0.1685920 secs]
1568.406: [GC 41602K->18499K(259264K), 0.0034100 secs]
1568.794: [Full GC 29429K->18048K(259264K), 0.1775530 secs]
1571.351: [Full GC 41276K->18129K(259264K), 0.1805000 secs]
1573.344: [Full GC 38881K->18195K(259264K), 0.1760390 secs]
1575.800: [Full GC 26060K->18243K(259264K), 0.1733030 secs]
1577.789: [Full GC 30691K->18180K(259264K), 0.1765060 secs]
1580.336: [GC 41540K->18408K(259264K), 0.0033330 secs]
1582.005: [Full GC 32348K->18433K(259264K), 0.1778330 secs]
1583.438: [GC 41793K->18751K(259264K), 0.0039520 secs]
1583.913: [Full GC 25360K->18656K(259264K), 0.1724900 secs]
1587.323: [Full GC 35278K->18824K(259264K), 0.1789120 secs]
1590.612: [GC 42183K->19194K(259264K), 0.0040080 secs]
1591.305: [Full GC 32714K->18075K(259264K), 0.1783630 secs]
1591.920: [Full GC 32296K->18141K(259264K), 0.1737070 secs]
1593.748: [ -
Hi,
I am getting a jvm Memory Leak when i try to load and parse XMLs. The version of JDK is 1.4.1_05. Has anyone faced this problem?
Any pointers to this will be very helpful.
Thanks
RajdeepThere is at least one bug associated with xml (although not because of it) which usually makes an appearance in long running applications.
http://forum.java.sun.com/thread.jsp?forum=31&thread=351925
If this is an internal application you could conceivably replace the StringBuffer class yourself to fix this. -
JVM 1.5.0_11 and libumem -- need stack trace help for memory leak
I'm trying to track down the cause of some memory growth in a java application. In my tests, the java heap appears to remain stable, but the overall memory footprint of the jvm process continues to grow (observed with pmap).
I've run my application with libumem and have found what appears to be the culprit, but the memory allocation is in libjvm.so and I'm looking for ideas what might cause it.
uname -a for my host
SunOS thehost 5.10 Generic_118822-18 sun4u sparc SUNW,Netra-440
Here is the trace from libumem:
1f81c4c0::bufctl_auditADDR BUFADDR TIMESTAMP THREAD
CACHE LASTLOG CONTENTS
1f81c4c0 1f81a470 ac018b4577a0 7
1f43f188 8cda6a4 0
libumem.so.1`umem_cache_alloc+0x210
libumem.so.1`umem_alloc+0x60
libumem.so.1`malloc+0x28
libjvm.so`void*os::malloc+0x28
libjvm.so`void*ResourceObj::operator new+0x38
libjvm.so`ThreadStackTrace::ThreadStackTrace #Nvariant 1+0x34
libjvm.so`void VM_ThreadDump::doit+0xcc
libjvm.so`void VM_Operation::evaluate+0x80
libjvm.so`void VMThread::run+0x6e0
libjvm.so`void*_start+0x208
libc.so.1`_lwp_start
What causes this invocation in the JVM? Is there a known memory leak associated with this?
Thanks in advance for the assistance.More on this issue. The included program will continually allocate memory on the process heap until the JVM cannot allocate memory and it exits with the following exception.
Exception java.lang.OutOfMemoryError: requested 16 bytes for C_Heap: ResourceOBJ. Out of swap space?
import java.lang.StackTraceElement;
import java.lang.Thread;
public class TraceIt {
public static void main(String[] args) {
System.out.println("Starting trace");
int i = 0;
while (true)
if (i%100 == 0) System.out.println(i);
StackTraceElement[] se = Thread.currentThread().getStackTrace();
i++;
} -
Easy to produce - Memory Leak in JVM Using thread
I was just debugging the problem with our server and got this error (not from the original code, I reproduced it with small code)
at java.lang.Thread.run(Unknown Source)
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at SomeObject.resursiveThreadGeneratorMethod(ThreadRecursionLeak.java:12
at ClientThread.run(ThreadRecursionLeak.java:27)
it is just a simple program generating thread recursively with a lock on an object
import java.lang.Runnable;
import java.lang.Thread;
// <<Objec/Monitor Class>>
class SomeObject{
public synchronized void resursiveThreadGeneratorMethod(int threadNumber, int k){
if(k<=0)
return;
else{
System.out.println("Thread: "+threadNumber + "call number: "+k);
Thread thread=new Thread(new ClientThread(this));
thread.start();
resursiveThreadGeneratorMethod(threadNumber,k-1);
// <<Thread Class>>
class ClientThread implements Runnable{
SomeObject someObject=null;
public static int threadNumber;
public ClientThread(SomeObject someObject){
this.someObject=someObject;
threadNumber++;
public void run(){
someObject.resursiveThreadGeneratorMethod(this.threadNumber,10);
// <<Driver Class>>
public class ThreadRecursionLeak{
public static void main(String [] args){
SomeObject someObject=new SomeObject();
Thread thread=new Thread(new ClientThread(someObject));
thread.start();
is there any way I can monitor JVM memory status (programatically), kill those threads leading to memory leak and send notification to the system admin.
We run JVM 1.4 on the server and need to address this issue as we do not have control over the code that can be submitted to the server, we just do some checks and then let it run on the servers.
Our main requirement is to keep JVM alive and kill all those code and report them.
Message was edited by:
rajanikant_malviyaYou can monitor the JVM with the
[url=http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/i
ndex.html]JVMPI if you're using the Sun JVM.This is native code that basically gets
notified anytime the JVM does something
interesting.
However, you're going to have a very difficult time
catching code that does what the code you show does.
I'm not sure I understand your environment - you
allow people to submit code and you run it? Are you
running it in the same JVM as your server? That
seems like a huge issue. A simple System.exit()
code will take down your server.
Let us know some more details.
We are actually having a portal through witch users can submit their code, witch are basically utility codes for different operations teams.
we then provide a way to schedule them.
At the background, we are having 6 (Win) servers where at each server we are having 20 to 25 users on different ports (managed by our application) running there own JVMs. When a schedule is met we just invoke a servlet (on any free port) and pass code id (stored in DB). And this servlet is responsible for compilation and exicution of the code (We just use Runtime to fork this new process).
I don't know, but is there any way through witch I can monitor this process and restrict to generate threads recursively??? -
Memory leak in "Tenured Generation" heap (JVM 1.5)?!
For about over a year, I'm trying to hunt down the memory leak in our server application. But after all the improvements I've made (especially with 'forgotten' listeners that didn't exist anymore), I'm confident that the application doesn't have a memory leak anymore. At least the new "jconsole.exe" tool of JDK 1.5 shows me a very intersting behaviour:
Even if the server app is doing nothing than one thread polling a database table for possible new jobs to process, the memory slightly increases over time ... very slightly. It's just like the screenshot at
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html#memory
where you might find a very slight tendency up. I run jconsole the whole day to track the application on a computer where no jobs got processed, so the application only sit there there whole day and just one thread has a loop that polls a database table via JDBC and doesn't get a result. The result is, that the memory chart is like the chart in the screenshot of the link above just with much more jaggies. About every 20 minutes, garbage collection seems to kick in, as the jaggie line drops about several megabytes just to increase again slowly.
Of course the thread loop creates objects but it doesn't hold any (debugged it several times and it is quite easy code). So this behaviour makes sense. But it doesn't make sense that the memory usage overall slowly increases over many hours (ultimativaly leading to an OutOfmemoryError).
So far, I still thought, it must be a memory leak in my application. But then, I played with jConsole and noticed this: if I just display the Memory Pool "Eden Space", the jagged line always drops down to the same level, i.e. no memroy leak. The "Survivor Space" is also constant in average (no memory leak). But the "Tenured Generation" line shows this memroy leak behaviour (slowly increases). This space is described as:
Tenured Generation (heap): pool containing objects that have existed for some time in the survivor space.
So, I'm not so sure anymore if this memory must be in my application. Unfortunately, jConsole doesn't show some kind of object tree that can be browsed and I would see what kind of object (collection) increase.
I tried profiling my application, but the profiled app runs so slowly that it would need many days or weeks until it's possible to identify some bad objects.
Is there another way to identify such memory waisters?Write a main() that does the polling in a tight loop 1000 times. Then System.gc(); Thread.sleep(1000); System.exit(). Run the thing with -Xrunhprof. Observe the "live bytes" and "live objs" columns in the generated java.hprof.txt file. Anything that strikes as suspicious? If every polling round leaks one object, there's likely to be 1000 (or N*1000) of something live. Make sure the leak is in the polling routine by running it 1,000,000 rounds and getting an OutOfMemory.
-
Memory leak in Solaris - SunOS 5.7, jre1.3.1
Hi,
I hava a java application that spawns about 100 threads. Each thread sends a request to WebLogic server 6.1. We are using Oracle 8.1.7. They are all running in a Sun box, 2 CPUs and 6gig memory.
JRE = 1.3.1
SunOS = 5.7
Weblogic = 6.1
Oracle = 8.1.7
(All running on the same box)
When we start the client application, running top shows that ,
the client JVM process - uses 40 MB of memory
WebLogic - uses 250 MB of memory
But the available memory comes down drastically (almost by 350 MB), and on bringing both the client and weblogic down, we are not able to get this 350 MB back
Running JProbe, doen not show any memory leak in our application
we are using the hotspot client version
-Xms = 128m
-Xmx = 128m
Any help is appreciatedIt looks like i am also facing the same problem with my application . If by some chance you were able to solve this problem do send a mail to [email protected] I just posted the question. while searching the web i found your question which looks similar but not answered. Hope you could give me some input
Thanks -
How Do I identify a Memory Leak?
I know this is not enought information but...
My application used 3 hashtables in a Data object to store application data. I retrive this data from an XML file. I also download XML and merge it into andother XML file. Some of these hashtables contain object that contain more hashtables.
I am trying to use JProbe Profiler to find the leak. I notice the memory increases when I load the data into objects and put them into hash tables. I also notice an increase when I am merging newly downloaded XML into the current XML data. I am useing Nodelists and NOdes to get the data.
Does anyone have any tips or suggestion on how to find a memory leak?
Thank you,
Al7 MB of XML file, loaded into a DOM? You realize, of
course, that DOMs are data structures that take up
memory, too, right?Yes I do. I load it into DOM then go through the Document and put the XML data into a custom file format (seialized objects). The data is sent from the server in the form of XML.
There's your problem. If you load X MB into memory
and keep it around as long as your application is
running, that's not necessarily a "leak". Yeah I realized this but it seems that if I load 7MB of my objects into hashtables my memory usage shouldn't increase by 30MB. I just assumed it would stay around 10MB.
The real issue is trading memory for CPU. If keeping
them in memory is crashing your app with OOM errors,
by all means just keep those objects in memory for as
long as you need them and then let the GC clean them
up. Don't put them in a Map, just let them have a
narrow method scope. Recreate them every time you
need them. Yes I'm beginning to see the light.
I'm sure you're thinking, "But recreating them will
cost CPU and slow down my app!" Yes, that's why it's
a tradeoff between memory and CPU.
Do you really need the whole document in memory at
once? If you're just cherry picking a few values out
of it, maybe you can use a SAX parser instead of a
DOM.
No I don't need all that data at once.
>
Either you're screwed or you need to rethink this.
You'd better hope that it's really not needed at
every moment for every client.After rethinking, I'm going to keep the serialized data in the file until I need it. Rather than searching through a hashtable for the object I want I will search the file.
What are your JVM settings for -Xms and -Xmx? Maybe
increasing those will do the trick.I did increase them and it helped a little, but I can still get a OutOfMemoryError if I try.
Are you sure these are the culprits? Have you
profiled the app to see if there are other sources of
leaks?Yes I have been profiling the application. It seems that there is a memory leek. I am just having trouble identifing it. I know the memory increases at 2 points. When I load the XML data into the DOM and when I load the DOM into my Custom object and then into the Hashtables.
Last resort? Buy more physical memory. It's cheap.I think I am going to keep unused data out of memory and access it form a file. After I make this change I think my memory usage will drop alot. I will profile again after I have this change made to see if there is a memory leak.
Thanks for you help,
Al -
JBoss EAP 6 On JRockit - Memory Leak
hello team.
I have memory leak problem on jboss and jrockit.
My Environment :
1. OS :
CentOS release 6.4 (Final)
2. JRockit :
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Oracle JRockit(R) (build R28.2.7-7-155314-1.6.0_45-20130329-0641-linux-x86_64, compiled mode)
3. Application Server:
JBoss EAP 6.2.0.GA
4. Application
Large EJB Application (100 and more EJB Beans (Stateless, Stateful, MDB, Timers and so on)
Everything works fine on older application server versions (4.3 , 4.2)
But now I have Problem
Of course I know that problem is new version - and i have discussion on JBoss forums.
but guys I have question about jrockit with you:
What is the option "Other" in memory ??
[jboss@jboss-new bin]$ jrcmd 17114 print_memusage
17114:
Total mapped 8457864KB (reserved=2983100KB)
- Java heap 3145728KB (reserved=0KB)
- GC tables 105232KB
- Thread stacks 46412KB (#threads=138)
- Compiled code 1048576KB (used=12257KB)
- Internal 1480KB
- OS 170324KB
- Other 3639056KB
- Classblocks 10496KB (malloced=9631KB #28393)
- Java class data 289536KB (malloced=192391KB #133697 in 28393 classes)
- Native memory tracking 1024KB (malloced=294KB #10)
[jboss@jboss-new bin]$
This size increases every time - and took entire amount of RAM.
Thank in Advance.
Regards,
Paata LominadzeNot sure what the 'other' is, but it is probably best shown by using an example. By using displayMap we can display a memory map of various JVM subsystems and libraries that are loaded, including third-party libraries.
./jrcmd 4523 print_memusage displayMap
Total mapped 3984796KB (reserved=2978740KB)
- Java heap 524288KB (reserved=0KB)
- GC tables 17548KB
- Thread stacks 20276KB (#threads=39)
- Compiled code 1048576KB (used=14224KB)
- Internal 1672KB
- OS 146924KB
- Other 2092648KB
- Classblocks 7424KB (malloced=7381KB #20064)
- Java class data 124416KB (malloced=124411KB #91048 in 20064 classes)
- Native memory tracking 1024KB (malloced=118KB #10)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OS *java r x 0x0000000000400000.( 76KB)
OS *java rw 0x0000000000612000.( 4KB)
OS *[heap] rw 0x00000000007c1000.( 132KB)
INT Poll r 0x000000007fffe000 ( 4KB)
INT Membar rw 0x000000007ffff000.( 4KB)
MSP Classblocks (1/2) rw 0x00000000df8c0000 ( 6912KB)
MSP Classblocks (2/2) rw 0x00000000dff80000 ( 512KB)
HEAP Java heap rw 0x00000000e0000000.( 524288KB)
OS *ld-2.12.so r x 0x0000003664400000.( 128KB)
OS *ld-2.12.so r 0x000000366461f000 ( 4KB)
OS *ld-2.12.so rw 0x0000003664620000 ( 4KB)
OS **ld-2.12.so rw 0x0000003664621000.( 4KB)
OS *gconv-modules.cache r 0x00007f8f2e4a0000 ( 28KB)
THREAD Stack 4630 rwx 0x00007f8f2e4a7000 ( 8KB)
THREAD Stack 4630 0x00007f8f2e4a9000 ( 12KB)
THREAD Stack 4630 rwx 0x00007f8f2e4ac000 ( 244KB)
MSP Java class data (5/37) rw 0x00007f8f2e4e9000 ( 14336KB)
MSP Java class data (9/37) rw 0x00007f8f2fa40000 ( 5888KB)
rw 0x00007f8f30000000 ( 188KB)
0x00007f8f3002f000 ( 65348KB)
rw 0x00007f8f34000000 ( 132KB)
0x00007f8f34021000 ( 65404KB)
rw 0x00007f8f38000000 ( 412KB)
0x00007f8f38067000.( 65124KB)
MSP Java class data (10/37) rw 0x00007f8f3c034000 ( 34048KB)
rw 0x00007f8f3e174000 ( 8200KB)
MSP Java class data (11/37) rw 0x00007f8f3e976000 ( 256KB)
OS *libhpi.so rw 0x00007f8fb37fc000 ( 8KB)
OS **libhpi.so rw 0x00007f8fb37fe000 ( 4KB)
CODE Compiled code rwx 0x00007f8fb37ff000 ( 64KB)
CODE Compiled code rwx 0x00007f8fb380f000 ( 128KB)
CODE Compiled code rwx 0x00007f8fb382f000 ( 64KB)
MSP Java class data (37/37) rw 0x00007f8ff83a1000 ( 512KB)
GC Modified Union Set (committed) rw 0x00007f8ff8421000 ( 132KB)
GC Card table rw 0x00007f8ff8442000 ( 1024KB)
GC Object bits (committed) rw 0x00007f8ff8542000 ( 8196KB)
Here
- thread is thread related (such as thread stacks)
- int, internal use (such as pointer pages)
- heap, chunk used by JRockit for the Java heap
- os, mapped directly from the operating system, such as third party DLLs or shared objects
- msp, memory space. a memory space is a native heap with a specific purpose, for example native memory allocation inside the JVM
- gc, garbage collection related, for example live bits
- code, compiled code
The 'other' memory space looks to me (from the blank entries in the above print-out) like they are a memory pages to are still not used. When the JVM starts it mappes an amount of memory. To my knowledge JRockit uses mmap (mmap(2) - Linux manual page), which creates a new mapping in the virtual address space. JRockit reserves an amount of memory (Java Heap (heap where your object instances go) + its own runtime (all the others)).
To see where the growth is in the various memory spaces, you can use 'print_memusage baseline', after which you can execute print_memusage again, for example,
./jrcmd 4523 print_memusage scale=M
4523:
Total mapped 3896MB +4MB (reserved=2905MB -3MB)
- Java heap 512MB (reserved=0MB)
- GC tables 17MB
- Thread stacks 19MB (#threads=39)
- Compiled code 1024MB (used=14MB +1MB)
- Internal 1MB
- OS 143MB
- Other 2043MB
- Classblocks 7MB (malloced=7MB #20596 +532)
- Java class data 126MB +4MB (malloced=125MB +4MB #93640 +2592 in 20596 classes)
- Native memory tracking 1MB (malloced=0MB #20 +10)
Note the additional column that prints out the difference in memory usage in relation to the baseline. You can also monitor native allocations by using trace_alloc_sites, memory allocations can then be displayed with different levels of detail using the level argument.
./jrcmd 4523 print_memusage trace_alloc_sites=true
4523:
Total mapped 3989660KB +4864KB (reserved=2974732KB -4008KB)
- Java heap 524288KB (reserved=0KB)
- GC tables 17548KB
- Thread stacks 20276KB (#threads=39)
- Compiled code 1048576KB (used=15265KB +1040KB)
- Internal 1672KB
- OS 146924KB
- Other 2092648KB
- Classblocks 7680KB +256KB (malloced=7669KB +287KB #20596 +532)
- Java class data 129024KB +4608KB (malloced=128967KB +4555KB #93640 +2592 in 20596 classes)
- Native memory tracking 1024KB (malloced=236KB +118KB #20 +10)
./jrcmd 4523 print_memusage level=3
4523:
Total mapped 3989660KB +4864KB (reserved=2974732KB -4008KB)
- Java heap 524288KB (reserved=0KB)
- GC tables 17548KB
- Thread stacks 20276KB (#threads=39)
- Compiled code 1048576KB (used=15265KB +1040KB)
- Internal 1672KB
- OS 146924KB
- Other 2092648KB
- Classblocks 7680KB +256KB (malloced=2KB -7379KB #4 -20060) Not fully traced
- Java class data 129024KB +4608KB (malloced=26KB -124385KB #16 -91032 in 20596 classes) Not fully traced.
- Native memory tracking 1024KB (malloced=118KB #10) Not fully traced.
gather_memorymap_database memtrace.c: 206 91KB +91KB (#1 +1)
gather_memory_usage osal_mspace.c:5142 7KB +7KB (#4 +4)
msGatherMSpacesUsageDatabase osal_mspace.c:6128 2KB +2KB (#1 +1)
msGatherMSpacesUsageDatabase osal_mspace.c:6134 16KB +16KB (#1 +1)
Note this is more on the JVM level, in your case in might be beneficial to investigate what is happening on the java heap. By using print_object_summary you can get insight how memory on the heap is used on a per-class basis. To get to the bottom of where the memory leak is you can use the memory-leak-detector (an example of its use can be found here Middleware Snippets: Fast, Faster, JRockit). You can also obtain a heapdump that can be analyzed by using for example MAT (see for an example here Middleware Snippets: Visualizing Class Loading). To obtain a heapdump you can run the command, for example,
[weblogic@machine1 bin]$ ./jrcmd 4523 runsystemgc full=true fullcompact=true
4523:
[weblogic@machine1 bin]$ ./jrcmd 4523 hprofdump filename=/home/weblogic/dump.hprof
4523:
Wrote dump to /home/weblogic/dump.hprof
Note that this first issues a full GC by using the runsystemgc command. -
Memory leak in WLS6.1 sp3 on Solaris?
We are running WLS 6.1 sp3 on Solaris 8 using Sun's 1.3.1 JVM with BEA's
JDriver to connect to Oracle (8.1.7). We have set the JVM to a maximum heap
of 512M (-Xms256m -Xmx512m).
The issue is that we are now seeing (via pmap) the resident memory growing
to ~1GB. Yet, the WLS management console is reporting memory usage of ~200M.
So, if we are to believe WLS, then the JVM (or some native library) is
chewing up the extra memory.
Having examined the results of "pmap -x <pid>", I see the heap (and some
anon) mem/file are quite large.
Address Kbytes Resident Shared Private Permissions Mapped File
00026000 418912 416096 - 416096 read/write/exec [ heap ]
D8C00000 524288 447928 - 447928 read/write/exec [ anon ]
total Kb 1083832 981136 37960 943176
Questions:
- Are there any known memory leaks with 6.1 sp3 on Solaris?
- Should it be possible for pmap's value of "heap" to grow larger than the
"Xms" setting? We have observed this recently, but the numbers above don't
reflect this.
- Any idea what the "anon" is or how to determine what it is?
- Do you know of any tools that might help me determine what is using that
memory or what is in it?
Any suggestions will be greatly appreciated...
Thanks in advance,
ErikIf you set -Xmx512m then the java heap will grow no larger than 512MB.
WLS is reporting the size of the java heap. (It is a java program after
all and doesn't know a lot about what native code might be doing.)
My first thought is try running with Oracle's thin (type-4) driver.
Since this is java code, it will use the java heap. If the memory usage
drastically changes, then you can point the finger at the jDriver.
Are you using any other native code / libraries?
-- Rob
Erik Westland wrote:
We are running WLS 6.1 sp3 on Solaris 8 using Sun's 1.3.1 JVM with BEA's
JDriver to connect to Oracle (8.1.7). We have set the JVM to a maximum
heap
of 512M (-Xms256m -Xmx512m).
The issue is that we are now seeing (via pmap) the resident memory growing
to ~1GB. Yet, the WLS management console is reporting memory usage of
~200M.
So, if we are to believe WLS, then the JVM (or some native library) is
chewing up the extra memory.
Having examined the results of "pmap -x ", I see the heap (and some
anon) mem/file are quite large.
Address Kbytes Resident Shared Private Permissions Mapped File
00026000 418912 416096 - 416096 read/write/exec [ heap ]
D8C00000 524288 447928 - 447928 read/write/exec [ anon ]
total Kb 1083832 981136 37960 943176
Questions:
- Are there any known memory leaks with 6.1 sp3 on Solaris?
- Should it be possible for pmap's value of "heap" to grow larger than the
"Xms" setting? We have observed this recently, but the numbers above don't
reflect this.
- Any idea what the "anon" is or how to determine what it is?
- Do you know of any tools that might help me determine what is using that
memory or what is in it?
Any suggestions will be greatly appreciated...
Thanks in advance,
Erik -
I have used BlazeDS in an application to push the data in realtime. However, we have been experiencing a heavy memory leak in the application. The application has a scheduler that pushes the data every one minute into the default queue. Without any browsers opened, the appication remain stable. And closing the browsers also cleans up the FlexClient object and other associated objects for that browsers. But the leak occurs when we open and keep browsers for a long period, say 2 to 3 days. The memory usage of application gradually increases and throws a "java.lang.OutOfMemoryError: Java heap space" Exception. On analyzing the HeapDump, I found that there are thousands of AsyncMessage Objects in the memory, not getting garbage-collected. This the channel definiton congured in services-config.xml file
<channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>true</polling-enabled>
<polling-interval-seconds>4</polling-interval-seconds>
<invalidate-session-on-disconnect>true</invalidate-session-on-disconn ect>
</properties>
</channel-definition>
Does anyone know the cause of this issue and how it can be overcome. Please help.We also have the same problem. The JVM goes out of memory every 24 - 50hrs. I have documented a working fix for the problem on the JVM side.
http://in-finite.me/fixing-blazeds-polling-amf-memory-leak/@ -
I've been writing a multi-threaded, non-blocking I/O game server and I'm kinda taking a break from hammering out code at the moment to analyze how efficient the server is. With 100-300 clients each transmitting data and receiving a proper response once every second or so, the server has almost 0% CPU load (on an AMD 4000+ 64bit CPU) so I am very happy with this.
However, I find that with -verbose:gc on, I can watch the memory every so slowly leak away.. for instance, I will lose around 3 kb / minute with an initial stack of 128mb, 256mb max with a few clients, and this can get as high as 100kb / minute with 200 clients hammering the server. I have looked quite hard at the code and I cannot see anywhere where I am continuously allocating memory and retaining references to it, so everything should be getting GC'd, but some additional kilobytes remain after each GC.
What I am wondering is, how can I profile the memory usage to, for instance, have an up-to-date count of how many objects of type X (including Strings and ArrayLists and stuff) that are currently in existance at any given time? This would at least give me a better idea of where this potential memory leak is?
Thanks in advance,
JamesYou may find the JVM is still warming up. It attempts to optimise as it goes and can still be consuming more memory as it re-optimises.
Maybe you are looking for
-
Account keys for movement type 201.
Hi Friends, Can anybody tell me, what are the account keys (tran/event keys) we will set for movement type 201. And why we are setting that. Kindly resolve my doubt please. Regards, Prasath
-
My ipod touch seems to have updated on its own, and now I can't access the songs, show a red circle with a red dot in the center. Computer says the songs are still on the ipod. Fix?
-
2311x Monitor broken when first used! Please help!
I had bought an HP 2311x and when I received it I hooked it up and the screen has alot of different colors, lines, and blurryness. Now after I hooked the monitor up to my pc I checked all the connections and power and everything was working fine. I
-
Hello I am using SDK1.4.1_02. I thought the jaws.jar was a part of the sdk but when I try to run an app that needs the netscape.javascript package I get the error message that it cannot resolve the symbol. My path setting for Windows XP is: C:\j2sdk1
-
How long does it take for the newest update to completely download, if we are caught up on all updates up to 3.0? I am trying to figure out when to download since it is very busy right now. Thanks.