Array garbage collection
I need to keep track of what objects got garbage collected in a program.
So I made sure that the classes of interest have a 'finalize()' method that simply print out the toString() and reference of the garbage collected object (using System.identityHashCode(this)).
This worked fine for all objects except arrays.
I went as far as substituting my own version of java.lang.Object that has an appropriate finalize(), but still no finalize() method seem to be getting called when an array object is 'supposed' to be garbage collected (the process consumes most of the system memory...)
Any thoughts?
Thanks,
Wes
Just an idea. You can try using WeakReference. Rather than using finalize, you can use the clear method of Reference.
Here is some pseudo code
.. class GCWatcher{
List wrl = ...
public void watch(Object obj){
wrl.add(new WatchableWeakReference(obj));
.. class WatchableWeakReference{
WathableWeakReference(Object obj){
super(obj);
public void clear(){
wrl.remove(this);
Object obj = get();
print out your message
super.clear();
If you try it let me know if it worked.
Similar Messages
-
This byte array is not garbage collected?
imageBytes[] does not seem to ever be garbage collected. I've pinpointed a SINGLE LINE that, when commented out, will prevent the memory leak. What could possibly be wrong with this line?
Running this code results in a "OutOfMemoryError: Java heap space" after roughly a minute on my machine. I'm using JRE version 1.5.0_08.
import javax.imageio.ImageIO;
import java.awt.*;
import java.awt.image.*;
import java.io.*;
// creates images to send to ImageConsumer
public class ImageProducer {
static BufferedImage bufferedImage;
static Robot robo;
static byte[] imageBytes;
public static void main(String args[]) {
try {
robo = new Robot();
} catch(Exception e) {
e.printStackTrace();
PipedOutputStream pos = new PipedOutputStream();
new ImageConsumer(pos).start();
bufferedImage = robo.createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()));
try {
ObjectOutputStream oostream = new ObjectOutputStream(pos);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(bufferedImage, "JPG", baos);
baos.flush();
imageBytes = baos.toByteArray();
while (true) {
ImageIO.write(bufferedImage, "JPG", baos);
baos.flush();
// THIS SEEMS TO BE WHERE THE MEMORY LEAK OCCURS: imageBytes
// If you comment the following line out, there will be no
// memory leak. Why? I ask that you help me solve this.
imageBytes = baos.toByteArray();
baos.reset();
oostream.writeObject(imageBytes);
pos.flush();
} catch (Exception e) {
e.printStackTrace();
// This thread reads the image data into bImg
class ImageConsumer extends Thread {
BufferedImage bImg;
PipedInputStream pis;
ImageConsumer(PipedOutputStream pos) {
try {
pis = new PipedInputStream(pos);
} catch (IOException e) { e.printStackTrace();}
public void run() {
try {
ObjectInputStream oinstream = new ObjectInputStream(pis);
while (true) {
byte[] imageBytes = (byte[])oinstream.readObject();
ByteArrayInputStream bais = new ByteArrayInputStream(imageBytes);
bImg = ImageIO.read(bais);
} catch (Exception e) {e.printStackTrace();}
}while (true) {
ImageIO.write(bufferedImage, "JPG", baos);
baos.flush();
// THIS SEEMS TO BE WHERE THE MEMORY LEAK OCCURS: imageBytes
// If you comment the following line out, there will be no
// memory leak. Why? I ask that you help me solve this.
imageBytes = baos.toByteArray();
baos.reset();
oostream.writeObject(imageBytes);
pos.flush();
}I have only briefly gone through the code, but why are you flushing it right before calling that line. Won't the byte array returned always be empty right after flushing the stream? -
Hi,
In a cache of Java objects, if size of most of the objects change very frequently does it impact Garbage collection? Please note number of objects are same only their size changes. Will GC be able to handle this scenario? Please can you send me pointers to any docs on this subject.
ThanksJoachimSauer wrote:
But then, if we accept that the size of an object itself doesn't change, nor do any of the dependenciesNot necessarily:
public Class MyMutableString {
private char[] data;
public MyMutableString(String s) {
data = s.toCharArray();
public MyMutableString(char[] d) {
data = d.clone();
public void setCharAt(int i, char c) {
data[i] = c;
public void setValue(String s) {
data = s.toCharArray();
public String toString(
return new String(data);
}While the size of this object (according to my "restricted" definition) is always the size of the single reference (plus whatever Java needs for its bookkeeping), it can reference different character arrays during its lifetime (thanks to the setValue method) and thus reference objects of different sizes.But the size of the reference doesn't change, ever. A reference to a char[] is the same size, regardless of the capacity of the array, and the array is not part of the object that's referencing it
I think we're just nit-picking terminology now, which wasn't where I meant to go. I was curious what the OP considered "size" to mean, but the bloody aliens have taken him up again -
SAX XML Parsing and Garbage Collection
I'm writing an XML parser that is running extremely slow while parsing large documents, I believe due to garbage collection. The implementation just overloads the DefaultHandler and hands that to a SAX Parser. This works fine on 2500 line XML document, taking on average a second or two, but becomes untennable when the document size is increased by a factor of 10 (often taking 5+ minutes).
I come from a C++ background and haven't dealt with automatic garbage collection at an expert level, so I'd appreciate any help. Below is a snapshot garbage collection done while a 25000 line document being parsed. It looks to me as the young objects are staying small, but older objects are going between 13M and 90M and back again. Is that what's happening? Can anyone give me leads as to what to look? Thanks in advance.
[GC [DefNew: 6234K->0K(7168K), 0.0057359 secs] 15517K->13022K(101696K), 0.0057907 secs]
[GC [DefNew: 6235K->0K(7168K), 0.0057748 secs] 19257K->16762K(101696K), 0.0060357 secs]
[GC [DefNew: 6235K->0K(7168K), 0.0023584 secs] 22997K->18009K(101696K), 0.0024123 secs]
[GC [DefNew: 6236K->0K(7168K), 0.0040785 secs] 24245K->20502K(101696K), 0.0041315 secs]
[GC [DefNew: 4990K->0K(7168K), 0.0041025 secs] 25492K->22996K(101696K), 0.0041544 secs]
[GC [DefNew: 4990K->0K(7168K), 0.0041486 secs] 27987K->25491K(101696K), 0.0042022 secs]
[GC [DefNew: 4991K->0K(7168K), 0.0040782 secs] 30481K->27985K(101696K), 0.0041299 secs]
[GC [DefNew: 4991K->0K(7168K), 0.0040935 secs] 32976K->30479K(101696K), 0.0046294 secs]
[GC [DefNew: 4991K->0K(7168K), 0.0041433 secs] 35471K->32974K(101696K), 0.0041958 secs]
[GC [DefNew: 4992K->0K(7168K), 0.0041114 secs] 37966K->35469K(101696K), 0.0041634 secs]
[GC [DefNew: 6240K->0K(7168K), 0.0024190 secs] 41709K->36717K(101696K), 0.0024729 secs]
[GC [DefNew: 6240K->0K(7168K), 0.0041377 secs] 42957K->39212K(101696K), 0.0041972 secs]
[GC [DefNew: 4993K->0K(7168K), 0.0041234 secs] 44205K->41707K(101696K), 0.0041762 secs]
[GC [DefNew: 4993K->0K(7168K), 0.0042827 secs] 46701K->44203K(101696K), 0.0046299 secs]
[GC [DefNew: 4994K->0K(7168K), 0.0043195 secs] 49197K->46699K(101696K), 0.0043751 secs]
[GC [DefNew: 4994K->0K(7168K), 0.0042740 secs] 51693K->49195K(101696K), 0.0043293 secs]
[GC [DefNew: 4995K->0K(7168K), 0.0042044 secs] 54190K->51692K(101696K), 0.0042575 secs]
[GC [DefNew: 4995K->0K(7168K), 0.0042237 secs] 56686K->54188K(101696K), 0.0042762 secs]
[GC [DefNew: 4996K->1K(7168K), 0.0040036 secs] 59183K->56685K(101696K), 0.0040550 secs]
[GC [DefNew: 4996K->1K(7168K), 0.0042095 secs] 61680K->59182K(101696K), 0.0045992 secs]
[GC [DefNew: 4997K->1K(7168K), 0.0042193 secs] 64178K->61679K(101696K), 0.0042715 secs]
[GC [DefNew: 4997K->1K(7168K), 0.0042301 secs] 66675K->64176K(101696K), 0.0042818 secs]
[GC [DefNew: 4997K->1K(7168K), 0.0042726 secs] 69173K->66674K(101696K), 0.0043251 secs]
[GC [DefNew: 4998K->1K(7168K), 0.0042564 secs] 71671K->69172K(101696K), 0.0043084 secs]
[GC [DefNew: 4998K->1K(7168K), 0.0040301 secs] 74169K->71669K(101696K), 0.0040812 secs]
[GC [DefNew: 4999K->1K(7168K), 0.0042656 secs] 76668K->74168K(101696K), 0.0047255 secs]
[GC [DefNew: 4999K->1K(7168K), 0.0043100 secs] 79166K->76666K(101696K), 0.0043737 secs]
[GC [DefNew: 5000K->1K(7168K), 0.0043492 secs] 81665K->79165K(101696K), 0.0044034 secs]
[GC [DefNew: 5000K->1K(7168K), 0.0043165 secs] 84164K->81664K(101696K), 0.0043693 secs]
[GC [DefNew: 5001K->1K(7168K), 0.0044196 secs] 86663K->84163K(101696K), 0.0044735 secs]
[GC [DefNew: 5001K->1K(7168K), 0.0044439 secs] 89163K->86662K(101696K), 0.0044967 secs]
[GC [DefNew: 5001K->1K(7168K), 0.0043983 secs] 91662K->89161K(101696K), 0.0045313 secs]
[GC [DefNew: 5002K->1K(7168K), 0.0043422 secs] 94162K->91661K(101696K), 0.0043944 secs]
[GC [DefNew: 5002K->1K(7168K), 0.0044223 secs] 96662K->94160K(101696K), 0.0044757 secs]
[GC [DefNew: 5002K->1K(7168K), 0.0048545 secs][Tenured: 96659K->9291K(97032K), 0.0863445 secs] 99162K->9291K(104200K), 0.0913954 secs]I don't think I'm creating megabytes of data, not using hashes or other expandable arrays. I've copied and pasted some code from my overriding of a DefaultHandler to give better definition to the problem.
I'm working with TPTP right now as a profiler. Are there any others you'd recommend?
public void startElement(String uri, String localname, String qName, Attributes attribs)
throws SAXException
if(qName.equals("Line"))
attributes = attribs;
else if(qName.equals("Note"))
attributes = attribs;
else if(qName.equals("Selection"))
String idValue = attribs.getValue("id");
String oValue = attribs.getValue("off");
String lValue = attribs.getValue("len");
if(idValue != null && oValue != null && lValue != null)
if(isImport)
issueSelectionContainer.addUnloadedSelection(Integer.parseInt(idValue), Integer.parseInt(oValue), Integer.parseInt(lValue));
else
issueSelectionContainer.addSelection(Integer.parseInt(idValue), Integer.parseInt(oValue), Integer.parseInt(lValue));
else if(qName.equals("Issue"))
attributes = attribs;
if(qName.equals("IsFinal"))
isFinal = true;
public void endElement(String uri, String localname, String qName)
throws SAXException
if(textElement.length() > 0)
if(qName.equals("Line"))
String qmValue = attributes.getValue("qm");
String lnValue = attributes.getValue("ln");
String pgValue = attributes.getValue("pg");
boolean qm = (qmValue != null && qmValue.equalsIgnoreCase("true"));
short ln = (lnValue != null) ? Short.parseShort(lnValue) : 0;
short pg;
if(pgValue != null)
pg = Short.parseShort(pgValue);
page = pg;
else
pg = page;
lineContainer.addLine(textElement + '\n', ln, pg, qm, null);
else if(qName.equals("Note"))
String lnValue = attributes.getValue("line");
if(lnValue != null)
int line = Integer.parseInt(lnValue);
try
lineContainer.getLine(line).setNote(textElement);
catch (IndexOutOfBoundsException e)
throw new SAXException("XML/Data mismatch. Note on line \"" + line + "\" out of \"" + lineContainer.lineCount() + "\" lines", e);
else if(qName.equals("Issue") && isImport)
String idValue = attributes.getValue("id");
String cValue = attributes.getValue("color");
if(idValue != null && cValue != null)
issueSelectionContainer.addUnloadedIssueSelection(Integer.parseInt(idValue), new Color(Integer.parseInt(cValue)), textElement);
else if(qName.equals("Name"))
name = textElement;
else if(qName.equals("Description"))
description = textElement;
else if(qName.equals("CreationDate"))
date = getCalendarFromString(textElement);
textElement = "";
attributes = null;
public void characters(char buf[], int offset, int len)
throws SAXException
textElement = new String(buf, offset, len);
} -
DataGrid Garbage Collection problem
Hi,
I'm quite confused about the DataGrid component's garbage collection. I've made a simple test code which adds a datagrid to the display list. If I remove the component from its parent without clicking any item, the element is collected correctly. However, if I click an item, the datagrid is no longer removed. Otherwise, if I use the keyborad to navigate through the items, the component is removed.
The profiler doesn't display any inbound reference to the datagrid. So, what's the problem? Is Flex retaining any reference when I use the mouse?
Thanks in advance.Hi,
here it goes:
the main application:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
import com.adur.nodes.Child;
private var _child:Child;
private function onLinkClickHandler(event:MouseEvent) : void {
_linkButton.enabled = false;
_unlinkButton.enabled = true;
_child = new Child();
addChild(_child);
private function onUnlinkClickHandler(event:MouseEvent) : void {
_linkButton.enabled = true;
_unlinkButton.enabled = false;
removeChild(_child);
_child = null;
System.gc();
]]>
</mx:Script>
<mx:VBox width="100%" height="100%">
<mx:HBox width="100%" height="30">
<mx:Button id="_linkButton" width="100" label="Link" click="onLinkClickHandler(event)" />
<mx:Button id="_unlinkButton" width="100" label="Unlink" enabled="false" click="onUnlinkClickHandler(event)" />
</mx:HBox>
<mx:Box id="_content" width="100%" height="100%" />
</mx:VBox>
</mx:Application>
the Child class:
<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%" >
<mx:ArrayCollection id="collection">
<mx:source>
<mx:Array>
<mx:Object label="Option1" score="85" />
</mx:Array>
</mx:source>
</mx:ArrayCollection>
<mx:List dataProvider="{collection}" />
</mx:Canvas>
thanks harUI. -
Reconciling garbage collection, heap overview, and object stats
First, both the JRockit RuntimeAnalyzer and Console are great tools. We use
them extensively so thank you.
I'm trying to reconcile the numbers in these three tabs.
1. How do I reconcile the Runtime Analyzer and Console output?
- The Heap overview tab in our application profile shows Heap Overview as
83% free.
- However, the Garbage Collection tab of the profile and Console shows the
application as oscillating between 50 Meg and 200 Meg of heap used. That's
25% (50Meg/200Meg) to 100%(200Meg/200Meg) used. How do I interpret the 83%
vs. the 100%?
I don't believe the 83% free, but I'm skeptical that we consume 150Meg of
memory in 50 seconds.
2. How do I reconcile the Object stats with the Garbage collection?
- Take the top heap user at end of recording, character buffer. It's 22.8%
of heap using 6,328 KB. If the heap is actually only 34Meg ( 17% of 200Meg.
I get the 17% from the 83% free), then 22.8% makes sense.
- So what's in the 200Meg of heap?
I sent this recording to the JRA team if you want to look at it.
Thanks
JeffI've never heard it put that way. Very interesting.
"Johan Walles" <johan@spamalamadingdong> wrote in message
news:41bf0be3@mail...
Note that the time it takes for the garbage collector to do its thing
grows with the amount of live data.
What the garbage collector really does is more like retaining the live
data than disposing of the garbage.
Regards //Johan
Jeff wrote:
Staffan,
Thanks - you clearly answered my questions. Now the follow-on questions:
1. Is there a way to get insight into what the 'dead' data is composed
of?
2. Is this pattern of consuming 3x the live data in about a minute
'typical' or a disaster in the making?
I'm trying to get a sense of what a reasonable target of 'dead' data is.
The system processes about a meg of data per second, including database
writes.
Thanks
Jeff
"sla" <[email protected]> wrote in message
news:33533893.1102952170368.JavaMail.root@jserv5...
Hi Jeff,
I'll try to answer the questions.
1) The Heap overview in the application profile is a snapshot of the heap
at the end of a garbage collection. At this time only live data is still
on the heap. So it looks like you have 17% of the heap filled with live
data (and some overhead as seen in the Heap overview).
In the garbage collection tab you can see the heap usage oscillating
between 35-40MB and 200MB. The lower value is right after a garbage
collection and the higher value is right before a garbage collection. The
garbage collector clears out about 160MB of "dead" data from the heap.
This is the amount of temporary objects that you created during the
garbage collection cycles.
2) The Object statistics are also taken right after a garbage collection.
At this time there is 34M of live data on the heap and of these about 22%
is taken up by character arrays (not unusual).
At this time the rest of the 200MB heap is empty. It's been cleared of
all temporary objects and is ready for allocation of new objects.
I hope this answered your questions.
Regards,
/Staffan -
Managing gigabytes with Java garbage collection ?
I am at the early stage of Java development project (kind of a memory based database index server) which easily involves managing 500.000+ very large Java objects (array based as this is the only way to use memory efficiently in Java) + a couple of millions of smaller objects.
Most of the objects are long lived but some (query) operations involve temporary creation of several 100MB+ sized objects. The app should run on Windows or Unix\Linux and will probably require/use up to 1-2GB of RAM (max possible on typical 32bit OS). At best it should be able to run under the JDK1.3+ hotspot VM.
I am concerned that the garbage collection by the VM may be a problem. While the app does not have real-time requirements, most (query) operations ought to complete in less than a second. Frequent complete GC freezes of say 5+ seconds would not be acceptable.
Anyone with experience on this ? Do you expect that I will get a problem with Java garbage collection or am I too concerned about this ?Anyone with experience on this ? Do you expect that I
will get a problem with Java garbage collection or am
I too concerned about this ?With an application that size, yes, you will run into problems, unless you are very careful.
Not being familiar with your applications memory allocation and access patterns, it's hard to be more specific. Perhaps something like 1.4.1's incremental GC will help in your case, but simply getting the VM to allocate and manage 2GB of memory will be a challenge.
Caveat emptor..
(See if you can split your application into smaller applications that can be run in different virtual machines; as long as each application's virtual machine doesn't grow too large, the GC problem will be manageable, and more importantly, you'll be able to use more than 2GB of memory comfortably). -
BufferedWriter I/O Garbage Collection!?
Ack! I cannot come up with an I/O solution that doesn't produce a lot of objects for collection. I'm sure there has to be a way, but at this point I'm at a loss. I recently noticed after downloading Optimizeit and watching object creation, that everytime I write to an output stream (in my case it's BufferedWriter going out to a socket), it creates new byte[] objects in large quantities, which are then available for garbage collection. This normally wouldn't be an issue, but if I wrap my code around a for loop that outputs a lot of data, I've generated quite a lot of instances. (I have a memory leak somewhere in my code, looking at object creation is about all I can do to find it)
For example, assume I have a StringBuffer _Buffmessage.
I also have a character array out_message.
os is my outputStream.
os = new BufferedWriter(new OutputStreamWriter(clientSocket.getOutputStream()));
//loop through StringBuffer and copy into a character array to prevent creation of String object
//(alternative to using toString() method of StringBuffer
for(int i = 0 ; i < _Bufmessage.length(); i ++)
out_message[i] = _Bufmessage.charAt(i);
//write out character array to client
os.write(out_message, 0, _Bufmessage.length());
os.newLine();
os.flush();If I run this code around 2000 times, I end up generating thousands of instances of byte[] ready for collection after running os.flush(); There HAS to be a way around this, or should I even be concerned about this? Am I somehow creating an object for each byte in the stream?Here's a follow up and the solution I found. The two suggestions I recieved were:
Suggestion 1:
StringBuffer input;
OutputStream out;
out.write( input.toString().getBytes());
out.close();and Suggestion 2:
StringBuffer input;
OutputStream out;
byte[] outArray = input.toString().getBytes();
out.write(outArray,0,outArray.length );
out.close();However a combination of my original solution as well as the suggested solutions resulted in the fix. In Suggestion 1, every call to write would create an instance of string (bad) and then write the byte array. In Suggestion 2, every call would result in the creation of a string (bad), creation of a byte array(bad), and a dupe of that array into write (ick). This was really an issue since I was outputting around 3-4 thousand times. My final solution is as follows; creates no new instances and is able to write out to my outputstream:
byte[] outArray = new byte[2000]; //byte array for output
OutputStream os = clientSocket.getOutputStream(); //this is the socket outputstream to write to
//for loop here, processing data......
try
//fill the byte array with chars from StringBuffer - reuse the existing array to
//avoid multiple instances being created
for(count = 0 ; count < _Bufmessage.length(); count ++)
outArray[count] = (byte)_Bufmessage.charAt(count);
//cast a new line byte to the output
outArray[count] = (byte)'\n';
//write out the length of the string
os.write(outArray,0,_Bufmessage.length());
}viola my memory leak was plugged - data is written to output, no char[] or byte[], nor String instances are generated, and I can sleep! As a sidenote, I did end up converting to NIO, and the new I/O classes eliminate these problems. I thought I'd share the solution anyway. Thanks to you three who gave me suggestions and didn't give me a hard time being a first time poster ;) -
Garbage collection and closure
I am running a remote script from bridge that opens a complex dialog in photoshop. I need to run the dialog in photoshop because it displays fonts, styles and actions, which are not available in bridge.
When I close the dialog I return to my bridge script. If I repeated open the remote script with the complex dialog I continue to use up resources and the dialog opens more slowly each time.
If I run the remote script directly from the ESTK I still lose reources and it slows down, but not as significantly as when run as a remote script via bridgetalk.
I think this is caused by inner functions in my dialog, which are creating closures, which in turn are preventing garbage collection.
Has anyone experienced this and do you have any tips to prevent the performance degradation?Rory,
I've never seen that before. In PS, the script that displays the dialog executes, then the engine that ran it supposed to be destroyed. Should be no need for garbage collection. Running the script directly in ESTK still uses BridgeTalk, so I would expect little difference.
I'd be curious to know what's happening because each time you run the script, it should be using a fresh scripting engine in PS. Perhaps there's something preventing PS from releasing the engine when BridgeTalk is involved. It that's the case, it would be a bug.
I do have a suggestion - instead of switching to PS, why not ask PS to give you lists of fonts, styles, and actions? You could write a script that put all three into a an array:
// up here create the arrays
var a = new Array();
a[0] = fontArray;
a[1] = styleArray;
a[2] = actionArray;
a.toSource();
eval'ing the message body in the onResult handler would give you all the info you needed to show your dialog in Bridge. Both Bridge and PS use scriptUI, so the dialog you have written should work in either (once you get the information necessary to display it in Bridge). -
Hi. There is a question in scjp preparation and I wish to know more about the explained answer:
Given:
3. class Dozens {
4. int[] dz = {1,2,3,4,5,6,7,8,9,10,11,12};
5. }
6. public class Eggs {
7. public static void main(String[] args) {
8. Dozens [] da = new Dozens[3];
9. da[0] = new Dozens();
10. Dozens d = new Dozens();
11. da[1] = d;
12. d = null;
13. da[1] = null;
14. // do stuff
15. }
16. }
Which two are true about the objects created within main(), and eligible for garbage collection
when line 14 is reached?
A. Three objects were created
B. Four objects were created
C. Five objects were created
D. Zero objects are eligible for GC
E. One object is eligible for GC
F. Two objects are eligible for GC
G. Three objects are eligible for GC
Answer:
® ✓ C and F are correct. da refers to an object of type "Dozens array," and each Dozens object
that is created comes with its own "int array" object. When line 14 is reached, only the
second Dozens object (and its "int array" object) are not reachable.
Can anyone tell me why its mentioned that there are 5 objects are reported created here.
Also doesn't defining the array of objects create the objects? E.g., in the line number 8, I see three element array is created, doenst this mean 3 objects are instantiated?
Thanks>
Also doesn't defining the array of objects create the objects? E.g., in the line number 8, I see three element array is created, doenst this mean 3 objects are instantiated?
>
What is your reasoning for thinking that creating a PLACE to hold three instances has ANYTHING to do with creating those instances?
If you move three bar stools to the kitchen counter in your home does that automatically create a person sitting at each bar stool?
If you create an egg carton that can hold a dozen eggs does that automatically create 12 eggs? If it did why do we need chickens? -
Hello,
I have a question: The Java card VM supports no garbage collection. However, for example when I delete a byte array (byteArray = null;), how can I get the unused memory back?
Thanks in advance,
HarryYou can't, thats what 'no garbage collection' means. The memory is lost. It is recomended to allocate necessary memory during applet creation.
-
Hotspot core dumping during JVM garbage collection ?
We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
Any ideas gratefully accepted.
Here's a logfile excerpt from my applications showing the Hotspot error message :
=====================================================================================
08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
405.977: [Full GC#
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
# An error report file with more information is saved as hs_err_pid2600.log
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
=====================================================================================
The logfile referred to in the error message contains the following.
=====================================================================================
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
--------------- T H R E A D ---------------
Current thread (0x001484d8): VMThread [id=8]
siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
Registers:
O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
PC=0xfe141348 nPC=0xfe14134c
Top of Stack: (sp=0xf8781460)
0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
0xf8781470: 0000080f e54bab6c 0000080f 00000004
0xf8781480: 00487588 00000134 e54bab6c 00000004
0xf8781490: 00000001 00000000 f87814c0 fe17aef4
0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
0xf87814b0: 00148988 00148c10 00148d7c f8781880
0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
0xf87814d0: 00008800 00487588 fe141310 fe7d6454
Instructions: (pc=0xfe141348)
0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x141348]
V [libjvm.so+0x17aefc]
V [libjvm.so+0x2d557c]
V [libjvm.so+0x300ef8]
V [libjvm.so+0x301e84]
V [libjvm.so+0x2ff950]
V [libjvm.so+0x29df30]
V [libjvm.so+0x362b44]
V [libjvm.so+0x6436f0]
VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
0x00038238 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
=>0x001484d8 VMThread [id=8]
0x0015c3b0 WatcherThread [id=16]
VM state:at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
[0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
Heap
PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
Dynamic libraries:
0x00010000 /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
0xff350000 /usr/lib/libthread.so.1
0xff340000 /usr/lib/libdl.so.1
0xff200000 /usr/lib/libc.so.1
0xff390000 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
0xff1e0000 /usr/lib/libsocket.so.1
0xff2d0000 /usr/lib/libsched.so.1
0xff1b0000 /usr/lib/libCrun.so.1
0xff160000 /usr/lib/libm.so.1
0xff080000 /usr/lib/libnsl.so.1
0xff060000 /usr/lib/libmp.so.2
0xff030000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
0xfdfc0000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
0xfdf80000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
0xfdf50000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
0xfb7e0000 /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xe4190000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
0xe3bd0000 /dsdvlp/lib/5/libSolarisNatives.so
0xe3e90000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
VM Arguments:
jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
Environment Variables:
JAVA_HOME=/dsdvlp/java/jvm/jdk150
CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
SHELL=/bin/csh
DISPLAY=CLI00184.mfil.local:1.0
OS=5
--------------- S Y S T E M ---------------
OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
load average:2.24 2.67 2.68
CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(166384k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
don't want to waste your time chasing a bug that's already been fixed. -
High Eden Java Memory Usage/Garbage Collection
Hi,
I am trying to make sure that my Coldfusion Server is optomised to the max and to find out what is normal limits.
Basically it looks like at times my servers can run slow but it is possible that this is caused by a very old bloated code base.
Jrun can sometimes have very high CPU usage so I purchased Fusion Reactor to see what is going on under the hood.
Here are my current Java settings (running v6u24):
java.args=-server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:PermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.io.useCanonCaches=false -XX:+UseParallelGC -Xbatch ........
With regards Memory, the only memory that seems to be running a lot of Garbage Collection is the Eden Memory Space. It climbs to nearly 1.2GB in total just under every minute at which time it looks like GC kicks in and the usage drops to about 100MB.
Survivor memory grows to about 80-100MB over the space of 10 minutes but drops to 0 after the scheduled full GC runs. Old Gen memory fluctuates between 225MB and 350MB with small steps (~50MB) up or down when full GC runs every 10 minutes.
I had the heap set to 2GB initally in total giving about 600MB to the Eden Space. When I looked at the graphs from Fusion Reactor I could see that there was (minor) Garbage Collection about 2-3 times a minute when the memory usage maxed out the entire 600MB which seemed a high frequency to my untrained eye. I then upped the memory to 4GB in total (~1.2GB auto given to Eden space) to see the difference and saw that GC happened 1-2 times per minute.
Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often? i.e do these graphs look normal?
Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
Any other advice for performance improvements would be much appreciated.
Note: These graphs are not from a period where jrun had high CPU.
Here are the graphs:
PS Eden Space Graph
PS Survivor Space Graph
PS Old Gen Graph
PS Perm Gen Graph
Heap Memory Graph
Heap/Non Heap Memory Graph
CPU Graph
Request Average Execution Time Graph
Request Activity Graph
Code Cache GraphHi,
>Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often?
Yes normal to garbage collect Eden often. That is a minor garbage collection.
>Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
Sometimes it is good to set Eden (Eden and its two Survivor Spaces combined make up New or Young Generation part of JVM heap) to a smaller size. I know your thinking - what make it less, but I want to make it bigger. Give less a try (sometimes less = more, bigger not = better) and monitor the situation. I like to use -Xmn switch, some sources say to use other method/s. Perhaps you could try java.args=-server -Xmx4096m -Xms4096m -Xmn172m etc. I better mention make a backup copy of jvm.config before applying changes. Having said that now you know how you can set the size to bigger if you want.
I think the JVM is perhaps making some poor decisions with sizing the heap. With Eden growing to 1Gb then being evacuated not many objects are surviving and therefore not being promoted to Old Generation. This ultimately means the object will need to be loaded again latter to Eden rather than being referenced in the Old generation part of the heap. Adds up to poor performance.
>Any other advice for performance improvements would be much appreciated.
You are using Parallel garbage collector. Perhaps you could enable that to run multi-threaded reducing the time duration of the garbage collections, jvm args ...-XX:+UseParallelGC -XX:ParallelGCThreads=N etc where N = CPU cores (eg quad core = 4).
HTH, Carl. -
High cpu usage for garbage collection (uptime vs total gc time)
Hi Team,
We have a very high cpu usage issue in the production.
When we restart the server, the cpu idle time would be around 95% and it comes down as days goes by. Today idle cpu is 30% and it is just 6th day after the server restart.
Environemnt details:
Jrockit version:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-linux-ia32, Native Threads, GC strategy: parallel)
Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep
Number Of Processors: 4
Max Heap Size: 1073741824
Total Garbage Collection Time: 21:43:56.5
Uptime: 114:33:4.1
Total Garbage Collection Count: 420872
Total Number Of Threads: 198
Number Of Daemon Threads: 191
Can you guys please tell me what would be problem in the server which causing the high cpu usage?
One more thing I would like to know is that why the total number of threads is 198 when we specified the Executor pool size as 25? I agree that weblogic would create some threads for its maintenance but around 160 threads!!! something is wrong I guess.
Santhosh.
[email protected]Hi,
I'm having a similar problem, but haven't been able to resolve it yet. Troubleshooting is made even harder by the fact that this is only happening on our production server, and I've been unable to reproduce it in the lab.
I'll post whatever findings I have and hopefully we'll be able to find a solution with the help of BEA engineers.
In my case, I have a stand-alone Tomcat server that runs fine for about 1-2 days, and then the JVM suddenly starts using more CPU, and as a result, the server load shoots up (normal CPU utilization is ~5% but eventually goes up to ~95%; load goes from 0.1 to 4+).
What I have found so far is that this corresponds to increased GC activity.
Let me list my environment specs before I proceed, though:
CPU: Dual Xeon 3.06GHz
RAM: 2GB
OS: RHEL4.4 (2.6.9-42.0.2.ELsmp)
JVM build 1.5.0_03-b07 (BEA JRockit(R) (build dra-45238-20050523-2008-linux-ia32, R25.2.0-28))
Tomcat version 5.5.12
JAVA_OPTS="-Xms768m -Xmx768m -XXtlasize16k -XXlargeobjectlimit16k -Xverbose:memory,cpuinfo -Xverboselog:/var/log/tomcat5/jvm.log -Xverbosetimestamp"
Here are excerpts from my verbose log (I'm getting some HT warning, not sure if that's a problem):
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Detected SMP with 2 CPUs that support HT.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to determine if HT is enabled.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/0/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Trying to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: Failed to read from /dev/cpu/1/cpuid
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] HT is: supported by the CPU, not enabled by the OS, enabled in JRockit.
[Fri Oct 20 15:54:18 2006][22855][cpuinfo] Warning: HT enabled even though OS does not seem to support it.
[Fri Oct 20 15:54:55 2006][22855][memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
[Fri Oct 20 15:54:55 2006][22855][memory ] heap size: 786432K, maximal heap size: 786432K
[Fri Oct 20 16:07:30 2006][22855][memory ] Changing GC strategy to generational, parallel mark and parallel sweep
[Fri Oct 20 16:07:30 2006][22855][memory ] 791.642-791.874: GC 786432K->266892K (786432K), 232.000 ms
[Fri Oct 20 16:08:02 2006][22855][memory ] 824.122: nursery GC 291998K->274164K (786432K), 175.873 ms
[Fri Oct 20 16:09:51 2006][22855][memory ] 932.526: nursery GC 299321K->281775K (786432K), 110.879 ms
[Fri Oct 20 16:10:24 2006][22855][memory ] 965.844: nursery GC 308151K->292222K (786432K), 174.609 ms
[Fri Oct 20 16:11:54 2006][22855][memory ] 1056.368: nursery GC 314718K->300068K (786432K), 66.032 ms
[Sat Oct 21 23:21:09 2006][22855][memory ] 113210.427: nursery GC 734274K->676137K (786432K), 188.985 ms
[Sat Oct 21 23:30:41 2006][22855][memory ] 113783.140: nursery GC 766601K->708592K (786432K), 96.007 ms
[Sat Oct 21 23:36:15 2006][22855][memory ] 114116.332-114116.576: GC 756832K->86835K (786432K), 243.333 ms
[Sat Oct 21 23:48:20 2006][22855][memory ] 114841.653: nursery GC 182299K->122396K (786432K), 175.252 ms
[Sat Oct 21 23:48:52 2006][22855][memory ] 114873.851: nursery GC 195060K->130483K (786432K), 142.122 ms
[Sun Oct 22 00:01:31 2006][22855][memory ] 115632.706: nursery GC 224096K->166618K (786432K), 327.264 ms
[Sun Oct 22 00:16:37 2006][22855][memory ] 116539.368: nursery GC 246564K->186328K (786432K), 173.888 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117122.577: nursery GC 279056K->221543K (786432K), 170.367 ms
[Sun Oct 22 00:26:21 2006][22855][memory ] 117123.041: nursery GC 290439K->225833K (786432K), 69.170 ms
[Sun Oct 22 00:29:10 2006][22855][memory ] 117291.795: nursery GC 298947K->238083K (786432K), 207.200 ms
[Sun Oct 22 00:39:05 2006][22855][memory ] 117886.478: nursery GC 326956K->263441K (786432K), 87.009 ms
[Sun Oct 22 00:55:22 2006][22855][memory ] 118863.947: nursery GC 357229K->298971K (786432K), 246.643 ms
[Sun Oct 22 01:08:17 2006][22855][memory ] 119638.750: nursery GC 381744K->322332K (786432K), 147.996 ms
[Sun Oct 22 01:11:22 2006][22855][memory ] 119824.249: nursery GC 398678K->336478K (786432K), 93.046 ms
[Sun Oct 22 01:21:35 2006][22855][memory ] 120436.740: nursery GC 409150K->345186K (786432K), 81.304 ms
[Sun Oct 22 01:21:38 2006][22855][memory ] 120439.582: nursery GC 409986K->345832K (786432K), 153.534 ms
[Sun Oct 22 01:21:42 2006][22855][memory ] 120443.544: nursery GC 410632K->346473K (786432K), 121.371 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.508: nursery GC 411273K->347591K (786432K), 60.688 ms
[Sun Oct 22 01:21:44 2006][22855][memory ] 120445.623: nursery GC 412391K->347785K (786432K), 68.935 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.576: nursery GC 412585K->348897K (786432K), 152.333 ms
[Sun Oct 22 01:21:45 2006][22855][memory ] 120446.783: nursery GC 413697K->349080K (786432K), 70.456 ms
[Sun Oct 22 01:34:16 2006][22855][memory ] 121197.612: nursery GC 437378K->383392K (786432K), 165.771 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.496: nursery GC 469709K->409076K (786432K), 78.257 ms
[Sun Oct 22 01:37:37 2006][22855][memory ] 121398.730: nursery GC 502490K->437713K (786432K), 65.747 ms
[Sun Oct 22 01:44:03 2006][22855][memory ] 121785.259: nursery GC 536605K->478156K (786432K), 132.293 ms
[Sun Oct 22 01:44:04 2006][22855][memory ] 121785.603: nursery GC 568408K->503635K (786432K), 71.751 ms
[Sun Oct 22 01:50:39 2006][22855][memory ] 122180.985: nursery GC 591332K->530811K (786432K), 131.831 ms
[Sun Oct 22 02:13:52 2006][22855][memory ] 123573.719: nursery GC 655566K->595257K (786432K), 117.311 ms
[Sun Oct 22 02:36:04 2006][22855][memory ] 124905.507: nursery GC 688896K->632129K (786432K), 346.990 ms
[Sun Oct 22 02:50:24 2006][22855][memory ] 125765.715-125765.904: GC 786032K->143954K (786432K), 189.000 ms
[Sun Oct 22 02:50:26 2006][22855][memory ] 125767.535-125767.761: GC 723232K->70948K (786432K), 225.000 ms
vvvvv
[Sun Oct 22 02:50:27 2006][22855][memory ] 125768.751-125768.817: GC 712032K->71390K (786432K), 64.919 ms
[Sun Oct 22 02:50:28 2006][22855][memory ] 125769.516-125769.698: GC 711632K->61175K (786432K), 182.000 ms
[Sun Oct 22 02:50:29 2006][22855][memory ] 125770.753-125770.880: GC 709632K->81558K (786432K), 126.000 ms
[Sun Oct 22 02:50:30 2006][22855][memory ] 125771.699-125771.878: GC 708432K->61368K (786432K), 179.000 ms
So, I'm running with the default GC strategy which lets the GC pick the most suitable approach (single space or generational). It seems to switch to generational almost immediately and runs well - most GC runs are in the nursery, and only once in a while it goes through the older space.
Now, if you look at [Sun Oct 22 02:50:27 2006], that's when everything changes. GC starts running every second (later on it's running 3 times a second) doing huge sweeps. It never goes through the nursery again, although the strategy is still generational.
It's all downhill from this point on, and it's a matter of hours (maybe a day) before we restart the server.
I guess my only question is: What would cause such GC behavior?
I would appreciate your ideas/comments!
Thanks,
Tenyo -
IncompatibleClassChangeError. Caused by garbage collection?
The problem occurs on JDK 1.3.1-b24 compiled in JBuilder Windows and
running on Sun Solaris with identical JDK version.
The application is a relatively complex RMI server.
An error recovery function in the server runs in a Thread every two
minutes. Most of the time it has nothing to do and ends without
incident.
Occasionally conditions require recovery that may not be successful
for many attempts.
Part of the recovery is a simple debug display of parameters involved
in the recovery. There will be multiple displays during a single
recovery cycle.
In a recent example of problem, the recovery executed every two
minutes for over two hours with the debug display working
successfully.
Suddenly one display works successfully and 5 milliseconds later the
same display fails with a IncompatibleClassChangeError.
The last part of the stack trace is:
java.lang.IncompatibleClassChangeError
at [class name].toString([class name].java:74)
at java.lang.String.valueOf(String.java:1947)
at java.lang.StringBuffer.append(StringBuffer.java:370)
at java.util.AbstractMap.toString(AbstractMap.java:567)
at java.lang.String.valueOf(String.java:1947)
line 74 of class is
public String toString()
return _responses.toString();
where _responses is an ArrayList that has been stored on Map that
contains the parameters that is being display as part of the debug
information.
Once the failure occurs, it will always occur until the JVM is
restarted. This suggests to me that something in the JVM, maybe garbage collection, has either corrupted the in-memory copy of the class or some internal table used by the JVM has become corrupted.
Anybody else have ideas?java.lang.IncompatibleClassChangeError
at [class name].toString([class name].java:74)
at java.lang.String.valueOf(String.java:1947)
at
java.lang.StringBuffer.append(StringBuffer.java:370)
at
java.util.AbstractMap.toString(AbstractMap.java:567)
at java.lang.String.valueOf(String.java:1947)
Problem: The IncompatiableClassChangeError is a Symbolic resolution problem. In lamen's terms a package,class,method,or a variable name is corrupted.
Possible problem location: Are you using a Custom ClassLoader? Do you Load and compile on the fly?
where _responses is an ArrayList that has been stored
on Map that
I would look hard at the following methods in your MAP Interface:
public void clear();
public Object put(Object key,Object value);
public void putAll(Map t);
public Object remove(Object key);Is it possible that your MAP interface is corrupting your ArrayList using one of the above methods? Then, when you are building the strings using the AbstractMap's.toString() method, you are getting the IncompatiableClassChangeError?
This is word for word listing of the MAP Interface...V1.41.
Some map implementations have restrictions on the keys and values they may contain. For example, some implementations prohibit null keys and values, and some have restrictions on the types of their keys.
This puzzles me
Attempting to insert an ineligible key or value throws an unchecked exception, typically NullPointerException or ClassCastException.
What's this, they state above that you should get a unchecked Exception, but the first sentence below makes me assume they are pulling a query on an ineligible key or value???
Attempting to query the presence of an ineligible key or value may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter.
Oh,OK. They are basically saying it totally depends on how you implement this Interface <grin>
More generally, attempting an operation on an ineligible key or value whose completion would not result in the insertion of an ineligible element into the map may throw an exception or it may succeed, at the option of the implementation.
The "optional" they are talking about are the methods that I listed above.
Such exceptions are marked as "optional" in the specification for this interface.
Well you asked for ideas, so there's a brain fart for you?
...Hope this helps
Maybe you are looking for
-
Why can't I access the variables in my threads?
hello. another question about threads.. ========================== I have an inner class that implements Runnable (i.e. a thread) and has a variable in it. I want to be able to access that variable from outside the thread class so that I can set or r
-
Downloaded the latest iTune upgrade on my labtop and iTunes will not open?
It used to work fine before the upgrade. Now it will not open on my notebook--sorry not laptop. I even re-installed it, but no help.
-
How to call a WD Application from a function module?
Hi Folks, I have a requirement in my project to call my web dynpro application from a function module . Can someone help me out with this , some example or docs would be of great help . Regards Abhishek Sahai
-
Modify not allows to Edit file in Sequencer
Hi, I am trying to edit a file in Sequencer (5.0 sp2) that can be opened with Notepad after local installation. When right click on file there are : Add Delete Modify. When click Modify it provides the box for a path. I guess Modify means Replace...
-
Premiere Pro CS6 won't capture HDR-HC3 properly
In HDV capture mode it wants to assign an mp3 extension. Doesn't capture in native M2t format. Tried reinstalling. Haven't had this problem with previous versions. ver. 6.01