P3
FULL PRODUCT VERSION :
java version "1.6.0_11"
FULL OS VERSION :
Windows Server 2008
EXTRA RELEVANT SYSTEM CONFIGURATION :
Running on an Intel Xeon SR1550 server.
-server
Problem occurs when VM started with default memory but NOT when increased to xMX1024M
A DESCRIPTION OF THE PROBLEM :
It appears that in conditions of extreme stress the garbage collector is collecting items that still have short lived local method references to them.
Consider the following code :-
Message message;
while ((message=theMessageQueue.poll())!=null) {
theConnection.sendMessage(message);
}
What we are seeing is that the Message object is being garbage collected (the finalize method is called) whilst we are still in the sendMessage call. Because the finalize causes a ByteBuffer used by the message to be returned to a buffer pool, the buffer is reused by another thread which corrupts the message.
At the time the message is taken off the queue there would be no other references to it within the VM but we would expect the assignment to the local message variable to protect it from the garbage collector.
What seems to prove that this is the garbage collector is that if we replace the code above with the following code using an instance variable then the problem does not occur.
while ((theMessage=theMessageQueue.poll())!=null) {
theConnection.sendMessage(theMessage);
}
We see this occurring when processing very large numbers of messages and when memory is low. Increasing the VM memory to 1024M prevents the problem occurring in this case but we can not guarantee it will in all cases.
Though we have circumvented the problem in this case it is very worrying that objects referenced by local variables only can be garbage collected as this could have very serious repercussions.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We can reproduce the problem fairly consistently if we revert our code to the original example and reduce the memory. However, we have not tried to reproduce in isolation as this would be very difficult to set up.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
CUSTOMER SUBMITTED WORKAROUND :
Using instance variables solves the problem in this case but you can not use instance variables everywhere!
java version "1.6.0_11"
FULL OS VERSION :
Windows Server 2008
EXTRA RELEVANT SYSTEM CONFIGURATION :
Running on an Intel Xeon SR1550 server.
-server
Problem occurs when VM started with default memory but NOT when increased to xMX1024M
A DESCRIPTION OF THE PROBLEM :
It appears that in conditions of extreme stress the garbage collector is collecting items that still have short lived local method references to them.
Consider the following code :-
Message message;
while ((message=theMessageQueue.poll())!=null) {
theConnection.sendMessage(message);
}
What we are seeing is that the Message object is being garbage collected (the finalize method is called) whilst we are still in the sendMessage call. Because the finalize causes a ByteBuffer used by the message to be returned to a buffer pool, the buffer is reused by another thread which corrupts the message.
At the time the message is taken off the queue there would be no other references to it within the VM but we would expect the assignment to the local message variable to protect it from the garbage collector.
What seems to prove that this is the garbage collector is that if we replace the code above with the following code using an instance variable then the problem does not occur.
while ((theMessage=theMessageQueue.poll())!=null) {
theConnection.sendMessage(theMessage);
}
We see this occurring when processing very large numbers of messages and when memory is low. Increasing the VM memory to 1024M prevents the problem occurring in this case but we can not guarantee it will in all cases.
Though we have circumvented the problem in this case it is very worrying that objects referenced by local variables only can be garbage collected as this could have very serious repercussions.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We can reproduce the problem fairly consistently if we revert our code to the original example and reduce the memory. However, we have not tried to reproduce in isolation as this would be very difficult to set up.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
CUSTOMER SUBMITTED WORKAROUND :
Using instance variables solves the problem in this case but you can not use instance variables everywhere!