FULL PRODUCT VERSION :
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Server VM (build 20.4-b02, mixed mode)

java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode



ADDITIONAL OS VERSION INFORMATION :
Linux xxxx 2.6.5-7.244-bigsmp #1 SMP Mon Dec 12 18:32:25 UTC 2005 i686 i686 i386 GNU/Linux (Sles 9)
Linux xxxx2.6.16.54-0.2.12-smp #1 SMP Fri Oct 24 02:16:38 UTC 2008 i686 i686 i386 GNU/Linux (Sles 10.3)
Linux xxxx 2.6.24-19-server #1 SMP Wed Jun 18 15:18:00 UTC 2008 i686 GNU/Linux (Ubuntu 8 LTS)


A DESCRIPTION OF THE PROBLEM :
While running different applications on java 1.6.0_29 the operation system shows more and more memory usage until system freezes due to out of memory issues. The memory cannot be retrieved by stopping / restarting the JVM - only rebooting the system helps to gain back the memory. The memory usage of the running JVM is smaller than the memory "wasted" after a certain time of period. (an application using 500MB - Xmx) can kill a 16 GB system. JVMs are started with -server. The memory print of the JVM does not increase - top shows a constant memory usuage of the process but an increasing memory usuage.
Applications executed e.g. Tomcat, Glassfish and standalone JSE application.
All systems are working with 1.6.0_26 without any issues.

REGRESSION. Last worked in version 6u29

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Upgrade from 1.6.0_26 to 1.6.0_29 or _30

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
application running
top shows constant memory usuage of the java process - when stopping the java application the used memory must be freed and the total memory used should be the same as before
ACTUAL -
top shows an increasing total memory usuage - memory cannot be retrieved anymore wihtout reboot of system

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
any java application can cause this issue - it seems to be important that a lot of GC occur - tested with Glassfish V2, Tomcat 7 and different standalone applications
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
downgrade to 1.6.0_26 (security issue as 1.6.0_29 is currently latest security baseline).