<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.12-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Java memory profiling with jmap and jhat</title>
	<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat</link>
	<description>What happens at LShift</description>
	<pubDate>Tue, 06 Jan 2009 23:07:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.12-alpha</generator>

	<item>
		<title>by: Nirmal</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-139999</link>
		<pubDate>Wed, 15 Oct 2008 09:45:31 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-139999</guid>
					<description>&lt;p&gt;JHAT from JDK 1.6 can read heap dump xxx.hprof created automatically by JVM on OutOfMemoryError, but it can not read heap.bin generated by JMAP with -heap:format=b.&lt;/p&gt;

&lt;p&gt;More ever I am using &lt;b&gt;SAP Memory Analyzer&lt;/b&gt; which also cannot read heap.bin generated by JMAP with -heap:format=b.&lt;/p&gt;

&lt;p&gt;I need heap dumps at different points or scenarios while the application runs to identify memory related bottlenecks i.e. Heap Dump on Demand.&lt;/p&gt;

&lt;p&gt;Is there another way to take the &lt;b&gt;"Heap Dump on Demand" &lt;/b&gt;using JDK 1.5 so that I can use that heap dump in SAP Memory Analyzer?&lt;/p&gt;

&lt;p&gt;I have to use jdk 1.5 only....&lt;/p&gt;

&lt;p&gt;Thanks &#38; Regards,
Nirmal&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>JHAT from JDK 1.6 can read heap dump xxx.hprof created automatically by JVM on OutOfMemoryError, but it can not read heap.bin generated by JMAP with -heap:format=b.</p>
<p>More ever I am using <b>SAP Memory Analyzer</b> which also cannot read heap.bin generated by JMAP with -heap:format=b.</p>
<p>I need heap dumps at different points or scenarios while the application runs to identify memory related bottlenecks i.e. Heap Dump on Demand.</p>
<p>Is there another way to take the <b>&#8220;Heap Dump on Demand&#8221; </b>using JDK 1.5 so that I can use that heap dump in SAP Memory Analyzer?</p>
<p>I have to use jdk 1.5 only&#8230;.</p>
<p>Thanks &amp; Regards,<br />
Nirmal</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Aaron Boyd</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-8684</link>
		<pubDate>Fri, 25 Aug 2006 04:30:21 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-8684</guid>
					<description>&lt;p&gt;Looks like what Phillippe suggest for 1.4.2 vm's will only work on Solaris 1.4.2 vm's because jmap was only backported to 1.4 for Solaris.&lt;/p&gt;

&lt;p&gt;http://java.sun.com/j2se/1.4.2/ReleaseNotes.html&lt;/p&gt;

&lt;p&gt;Anyone managed to turn a &lt;em&gt;Linux&lt;/em&gt; 1.4.2 core into an hprof binary?  Any response very much appreciated.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Looks like what Phillippe suggest for 1.4.2 vm&#8217;s will only work on Solaris 1.4.2 vm&#8217;s because jmap was only backported to 1.4 for Solaris.</p>
<p>http://java.sun.com/j2se/1.4.2/ReleaseNotes.html</p>
<p>Anyone managed to turn a <em>Linux</em> 1.4.2 core into an hprof binary?  Any response very much appreciated.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Philippe Lantin</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-5629</link>
		<pubDate>Thu, 27 Jul 2006 22:53:12 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-5629</guid>
					<description>&lt;p&gt;Workaround for buggy/unusable jhat heap format behavior:&lt;/p&gt;

&lt;p&gt;1) grab the core using gcore or similar
2) generate an hprof binary from the core
3) load the hprof binary using jhat from jdk16 beta 1 (beta2 proved to be buggy)&lt;/p&gt;

&lt;p&gt;I am able to analyze cores from 1.4.2 vm's using jhat this way.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Workaround for buggy/unusable jhat heap format behavior:</p>
<p>1) grab the core using gcore or similar<br />
2) generate an hprof binary from the core<br />
3) load the hprof binary using jhat from jdk16 beta 1 (beta2 proved to be buggy)</p>
<p>I am able to analyze cores from 1.4.2 vm&#8217;s using jhat this way.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Henry Goff</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-5055</link>
		<pubDate>Sat, 15 Jul 2006 00:07:13 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-5055</guid>
					<description>&lt;p&gt;Having exactly the same problem as matthias. JHAT from JDK 1.6 can read heap dump xxx.hprof created automatically by JVM on OutOfMemoryError, but it can not read heap.bin generated by JMAP with -heap:format=b. Same with Yourkit - it can read .hprof dump but not heap.bin. Also tried jmap from JDK 1.6 to connect to server runing under JDK 1.5.0_07 but jmap from 1.6 can not connect to older JVMs.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Having exactly the same problem as matthias. JHAT from JDK 1.6 can read heap dump xxx.hprof created automatically by JVM on OutOfMemoryError, but it can not read heap.bin generated by JMAP with -heap:format=b. Same with Yourkit - it can read .hprof dump but not heap.bin. Also tried jmap from JDK 1.6 to connect to server runing under JDK 1.5.0_07 but jmap from 1.6 can not connect to older JVMs.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: david</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-3067</link>
		<pubDate>Mon, 05 Jun 2006 16:29:03 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-3067</guid>
					<description>&lt;p&gt;In our application, we were creating new system states in order to support different class loaders and python paths, for every request. The solution was simply to cache these - so there was only a single instance for each class loader.&lt;/p&gt;

&lt;p&gt;In fact we did this only indirectly - by keeping the python objects themselves, and invoking methods on them, rather than executing scripts for each request. This is much faster anyway.&lt;/p&gt;

&lt;p&gt;If the web application reloads you will still be left with unused system states attached to each thread, until all the new threads have been used in your application. This might still be a problem, depending on the servlet containers behaviour and the number of system states you need.&lt;/p&gt;

&lt;p&gt;A better (and easier) way is to make sure a servlet never leaks a system state:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;
    PySystemState old = Py.setSystemState(PyStateLoader.PYTHON_SYSTEM_STATE);
    try {
        ...
    }
    finally {
        Py.setSystemState(old);
    }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The first line will actually create the default system state the first time its called in the VM, and this will end up attaching that singleton state to all the threads.&lt;/p&gt;

&lt;p&gt;You could do this with a filter on you whole application.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>In our application, we were creating new system states in order to support different class loaders and python paths, for every request. The solution was simply to cache these - so there was only a single instance for each class loader.</p>
<p>In fact we did this only indirectly - by keeping the python objects themselves, and invoking methods on them, rather than executing scripts for each request. This is much faster anyway.</p>
<p>If the web application reloads you will still be left with unused system states attached to each thread, until all the new threads have been used in your application. This might still be a problem, depending on the servlet containers behaviour and the number of system states you need.</p>
<p>A better (and easier) way is to make sure a servlet never leaks a system state:</p>
<pre><code>
    PySystemState old = Py.setSystemState(PyStateLoader.PYTHON_SYSTEM_STATE);
    try {
        ...
    }
    finally {
        Py.setSystemState(old);
    }
</code></pre>
<p>The first line will actually create the default system state the first time its called in the VM, and this will end up attaching that singleton state to all the threads.</p>
<p>You could do this with a filter on you whole application.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: James Tauber</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-2924</link>
		<pubDate>Fri, 02 Jun 2006 21:56:42 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-2924</guid>
					<description>&lt;p&gt;So did you work out how to prevent the problem with Jython and Tomcat? I'm seeing the same thing.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>So did you work out how to prevent the problem with Jython and Tomcat? I&#8217;m seeing the same thing.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Alan</title>
		<link>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-318</link>
		<pubDate>Sun, 12 Mar 2006 08:59:07 +0000</pubDate>
		<guid>http://www.lshift.net/blog/2006/03/08/java-memory-profiling-with-jmap-and-jhat#comment-318</guid>
					<description>&lt;p&gt;The jmap -heap:format=b option which you found is not a documented option in J2SE 5.0. It was added in a 5.0 update to allow for the recovery of heap dump from a core file or hung process. As you noted, it takes considerable time to take a snapshot of a running process. If you download Mustang (Java SE 6) you'll find that jmap gets a new option called -dump which will do what you want. jmap -dump:file=  will write a snapshot of the heap to the specified file. It is relatively quick (a 700MB heap can typically be dumped to a file in 15-30 seconds depending on the speed of your system and disk). Also you'll find that jmap -histo is very fast and will not disrupt a production system.  The heap dump generated by the new -dump option will be parsable by jhat and you should not see any of the "Unrecognized heap dump..." and other errors which are observed when you recover a heap dump from a core file or process snapshot. As you noted, jhat is really only intended for rudimentary analysis but you can use the OQL interface to create your own queries. In time you can expect to see other profilers adding options to import these heap dumps.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>The jmap -heap:format=b option which you found is not a documented option in J2SE 5.0. It was added in a 5.0 update to allow for the recovery of heap dump from a core file or hung process. As you noted, it takes considerable time to take a snapshot of a running process. If you download Mustang (Java SE 6) you&#8217;ll find that jmap gets a new option called -dump which will do what you want. jmap -dump:file=  will write a snapshot of the heap to the specified file. It is relatively quick (a 700MB heap can typically be dumped to a file in 15-30 seconds depending on the speed of your system and disk). Also you&#8217;ll find that jmap -histo is very fast and will not disrupt a production system.  The heap dump generated by the new -dump option will be parsable by jhat and you should not see any of the &#8220;Unrecognized heap dump&#8230;&#8221; and other errors which are observed when you recover a heap dump from a core file or process snapshot. As you noted, jhat is really only intended for rudimentary analysis but you can use the OQL interface to create your own queries. In time you can expect to see other profilers adding options to import these heap dumps.</p>
]]></content:encoded>
				</item>
</channel>
</rss>
