src/content/community/articles/interviews/kirk-pepperdine.html - netbeans-website-cleanup - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
     <head>
         <title>Interview with NetBeans user Kirk Pepperdine</title>
         <meta name="description"
               value="Kirk Pepperdine, NetBeans user, in conversation
         about his work, performance tuning, memory leaks and usage of the NetBeans Profiler.">
         <link rel="stylesheet" href="https://netbeans.org/netbeans.css">
         <meta name="author" content="Gregg Sporar">
     </head>
     <body>
         <h1>Interview with NetBeans user Kirk Pepperdine</h1>

         <p><TABLE><tr>
                     <td><a href="http://kirk.blog-city.com/"><img
                         src="../../../images_www/articles/kirk-pepperdine.jpg" align="right" border="0"></a></td>
                     <td width="10">&nbsp;</td>
                     <td><p>Kirk Pepperdine works as an consultant, educator, and
                             author. He is a frequent speaker at conferences and is
                             a co-author of the book <i>Ant
                             Developer's Handbook</i>.  Kirk uses the NetBeans Profiler and
                             with the recent move of the Profiler into the standard NetBeans IDE
                             distribution in NetBeans 6.0 Milestone 8 he spent some time telling
                             us about his experiences with it.
                     </p></td>
                 </tr>
         </TABLE></P>

         <p><h3>Q: Kirk tell us a little bit about yourself and what you do.</h3>
         <p>A: I've been working with Java technologies for about 11 years, starting with when I
         began working for GemStone. I signed up because I wanted to
         work with their Smalltalk product but that plan didn't survive my first day
         there. Instead I got to work with their Java application server at a
         time when the term application server had yet to be defined. As for
         performance, well, I did some operational research performance
         work prior to working with Java so it was quite natural to continue
         doing performance work once I moved to working with Java. My current
         focus has been on imparting some of the things that I learned and
         continue to discover in my performance tuning course.

         <p><h3>Q: What sorts of tools do you use for performance tuning?</h3>
         <p>A: I get asked what my favorite tools are all the time. In reality I
         don't have a favorite tool. Well, ok, I take that back. My favorite
         tool is one that gives me the information I need to solve the problem
         at hand. That tool is the hero of the day. I say this because tools
         are like little eyes that give you a view on the system that you are
         studying. However they only give you a pin prick's view so if that
         view happens to give you what you need to know then it's got to be good.

         <p><h3>Q: When did you start using the NetBeans Profiler?</h3>
         <p>I don't really recall when I first ran into JFluild (the original Sun Labs project) but I've been watching it for quite some
         time. I really got very interested in it when I saw the NetBeans 6.0
         roadmap. As you know, I had been waiting on the arrival of Milestone 7 for quite
         some time and aside from a few hiccups, it hasn't disappointed.

         <p><h3>Q: What features of the NetBeans Profiler do you use?</h3>
         <p>A: My primary interest has been memory leaks. Even with all the tools
         out there - and there are some pretty decent ones, finding memory
         leaks is still very difficult. Recently I co-presented (with Dr.
         Heinz Kabutz) a University session at Javapolis where I wanted to give
         the attendees a solid methodology to find a leak by the end of the
         three hour session. What I didn't want was a problem with a class
         named ThisClassLeaks or something like that. I wanted to present on a
         real problem with enough code that you couldn't just stroll through
         the code and find it. The two features that stand out have been
         generations and the HeapWalker. They provide the answers to two of the
         three questions you need to answer when searching for a memory leak:  what, where, and why.

         <p><h3>Q: And what does generations tell you?</h3>
         <p>A: Generations is a very clever, very simple idea though it can be a
         bit tricky to understand at first. To understand generations you first
         have to understand how objects age. An object's age is determined by
         the number of garbage collections (GC) it has survived. Since most objects
         never survive more than a few microseconds, they rarely get very old.
         So you may have a handful of different ages for each class. Now let's
         say you create a cache of constant values that you initialize at the
         start of an application. These objects will survive every GC and
         consequently be very old. However you will still only have a handful
         of different ages for those objects. Even in a cache where objects are
         moved in and out on a regular basis you will most likely only have a
         handful of ages. Objects that are constantly leaking will have a large
         number of different ages.

         <p>So as you can see, the difference between
         objects that leak and objects that don't will most likely show up in
         the number of different ages or generations. The key is, once your
         application starts producing leaking objects it never stops. The
         result is that the leaking class will live in an ever increasing number of
         generations. So not only will the number be large, it will also be
         growing continuously. So this measurement is a really cool way to pick
         off this type of object leak.

         <p><h3>Q: Do you have a quick example that could help us better understand
         generations?</h3>
         <p>A: Sure,  let's say your program allocates three instances of class
         Foo when the program starts and then it never allocates any more Foo
         objects.  And it holds references to those three instances forever.
         Now let's say we look at the state of the application after the
         garbage collector has run 500 times. What is the generations value for
         the Foo class? The answer is 1 and it will stay 1. Now let's say that
         you also continuously create objects of class Bar that leak throughout the lifetime
         of the application. The generations value for class Bar will most
         likely be 500 and it will always be increasing.

         <p><h3>Q: So generations helps you identify "what" objects were leaking. What
         about "where" and "why"?</h3>
         <p>A: There are two things the NetBeans Profiler provides for that.
         First, during memory profiling it will show you which method allocated
         an object.  Sometimes just knowing where a leaking object was
         allocated is enough of a clue to let you figure out why it has not
         been garbage collected. But the answer to "where" the object is
         leaking can often be far away from where it is being created. This is
         one factor that makes finding leaks so challenging. This is where
         the NetBeans HeapWalker comes into play.

         <p><h3>Q: How does the NetBeans HeapWalker help?</h3>
         <p>A: The JVM's HPROF agent is the original heap profiler. When you have it enabled it
         will produce a complete picture of everything that is in your Java
         heap space. The NetBeans HeapWalker uses the binary output from HPROF to
         reconstruct a view of memory. With the NetBeans HeapWalker you can perform a visual
         inspection of everything in that reconstructed view. The problem here
         is that even for a trivial application the heap can contain a very
         large number of objects. Finding a particular set of leaking objects in a heap
         is like looking for a needle in a haystack so you really need to have
         other bits of information to help you direct your search. So if we
         combine the information culled from generations with the HeapWalker,
         we can zero in on a suspected leak.

         <p>Once you've got an instance of the leaking class selected in the HeapWalker,
         the HeapWalker can find the shortest path from that object to a GC root. Chances
         are pretty good that when we do that we will find a domain object that is either an
         implied collection or contains a collection that is responsible for
         causing the leak. Now this still doesn't answer the question of "why" but
         even getting this far is a huge step in the diagnostic process.

         <p><h3>Q: Can you tell us about how you've used the tools?</h3>
         <p>A: I've been anxiously awaiting the arrival of a stable
         version of this tool so I can put it through its paces. The
         M7 milestone is stable enough to fit that criteria. Before I use
         a tool in a live situation I want to be able to understand how to most
         effectively apply it. So I maintain a number of applications that leak
         in a couple of different ways. I've used M7 to diagnose the leaks in
         these applications. So far the results look very promising in that
         I've consistently been able to pick out signs of the leak very very
         quickly. It was this experience that lead me to include the tool in my
         performance tuning course even though it (version 6.0 of NetBeans) is still being
         baked.

         <p><h3>Q: How is the NetBeans Profiler being used in your training class?</h3>
         <p>A: Again this is all very early stuff so the first introduction was
         gentle. However the impact of the tool in the heap tuning section of
         the course was dramatic. Since performance tuning is mostly about
         getting used to looking at the output from tools and instrumentation
         there is quite a bit of emphasis on solving problems. One of the
         exercises is particularly nasty. It contains a whole bunch of well
         hidden problems that closely resemble stuff I see in the field. The
         exercise is free form in that anything goes. They can use any tool
         they like or even rewrite the entire application.

         <p>Everyone decided to
         use NetBeans to diagnose the memory leaks and the results were
         outstanding. This group managed to find leaks much faster and with far
         less difficulties than any group that had previously taken the course.
         It was very interesting to watch and I have started to use what I've
         learned during that session to restructure that portion of the course.

         <p><h3>Q: Starting with Milestone 8 of NetBeans 6.0, the Profiler will be
             included with the standard IDE installation.  You will no longer need
         to do a separate download and installation.  How does that sound to you?</h3>
         <p>A: The install of the NetBeans Profiler was pretty trivial to begin with but
         anything to make it easier is always good news.

         <p><h3>Q: Are there any features you would like to see added to the NetBeans Profiler?</h3>
         <p>I think it goes without saying that there are always going to be times
         when you wish a tool could do this or that so yes, there are a number of
         things that I'd like to see included in the NetBeans Profiler. However I'd like
         to focus on one large feature that I think would be most useful, the
         ability to analyze information being reported upon by the garbage
         collector. You can get this information using the JVM's -verbose:gc flag but as
         you can imagine, the information is quite cryptic. It also requires one
         to do quite a few calculations to extract useful information from these
         logs and there are currently only a handful of tools with this
         capability. The existing tools leave a lot of information on the table.
         They also are standalone so there is some analysis that is either
         extremely difficult or just impossible to obtain.

         <p>For example, if you could combine
         the GC logging information with an execution profile all of a sudden you
         have the ability to zero in on areas of your application that are
         responsible for a lot of object churn. As we start to run our
         applications on more and more cores, applications will be able to create
         more garbage at a much faster rate. This will put more pressure on the
         garbage collector which means that being able to identify loci of object
         churn is going to become increasingly more important.


         <br style="clear:both;" />
         <!-- ======================================================================================= -->

         <h2><a name="moreinfo"></a>Resources</h2>
         <p>For more information about using the NetBeans Profiler, see the following resources:
         </p>
         <ul>
             <li><a href="https://netbeans.org/features/java/profiler.html">Profiler Overview</a></li>
             <li><a href="http://profiler.netbeans.org/docs/help/5.5/getting_started.html">Profiler Basics</a></li>
             <li><a href="https://netbeans.org/kb/55/profiler-tutorial.html">Profiler Tutorial</a></li>
             <li><a href="http://profiler.netbeans.org/">Profiler project home page</a></li>
         </ul>

     </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<title>Interview with NetBeans user Kirk Pepperdine</title>
	<meta name="description"
	value="Kirk Pepperdine, NetBeans user, in conversation
	about his work, performance tuning, memory leaks and usage of the NetBeans Profiler.">
	<link rel="stylesheet" href="https://netbeans.org/netbeans.css">
	<meta name="author" content="Gregg Sporar">
	</head>
	<body>
	<h1>Interview with NetBeans user Kirk Pepperdine</h1>

	<p><TABLE><tr>
	<td><a href="http://kirk.blog-city.com/"><img
	src="../../../images_www/articles/kirk-pepperdine.jpg" align="right" border="0"></a></td>
	<td width="10"> </td>
	<td><p>Kirk Pepperdine works as an consultant, educator, and
	author. He is a frequent speaker at conferences and is
	a co-author of the book <i>Ant
	Developer's Handbook</i>. Kirk uses the NetBeans Profiler and
	with the recent move of the Profiler into the standard NetBeans IDE
	distribution in NetBeans 6.0 Milestone 8 he spent some time telling
	us about his experiences with it.
	</p></td>
	</tr>
	</TABLE></P>

	<p><h3>Q: Kirk tell us a little bit about yourself and what you do.</h3>
	<p>A: I've been working with Java technologies for about 11 years, starting with when I
	began working for GemStone. I signed up because I wanted to
	work with their Smalltalk product but that plan didn't survive my first day
	there. Instead I got to work with their Java application server at a
	time when the term application server had yet to be defined. As for
	performance, well, I did some operational research performance
	work prior to working with Java so it was quite natural to continue
	doing performance work once I moved to working with Java. My current
	focus has been on imparting some of the things that I learned and
	continue to discover in my performance tuning course.

	<p><h3>Q: What sorts of tools do you use for performance tuning?</h3>
	<p>A: I get asked what my favorite tools are all the time. In reality I
	don't have a favorite tool. Well, ok, I take that back. My favorite
	tool is one that gives me the information I need to solve the problem
	at hand. That tool is the hero of the day. I say this because tools
	are like little eyes that give you a view on the system that you are
	studying. However they only give you a pin prick's view so if that
	view happens to give you what you need to know then it's got to be good.

	<p><h3>Q: When did you start using the NetBeans Profiler?</h3>
	<p>I don't really recall when I first ran into JFluild (the original Sun Labs project) but I've been watching it for quite some
	time. I really got very interested in it when I saw the NetBeans 6.0
	roadmap. As you know, I had been waiting on the arrival of Milestone 7 for quite
	some time and aside from a few hiccups, it hasn't disappointed.

	<p><h3>Q: What features of the NetBeans Profiler do you use?</h3>
	<p>A: My primary interest has been memory leaks. Even with all the tools
	out there - and there are some pretty decent ones, finding memory
	leaks is still very difficult. Recently I co-presented (with Dr.
	Heinz Kabutz) a University session at Javapolis where I wanted to give
	the attendees a solid methodology to find a leak by the end of the
	three hour session. What I didn't want was a problem with a class
	named ThisClassLeaks or something like that. I wanted to present on a
	real problem with enough code that you couldn't just stroll through
	the code and find it. The two features that stand out have been
	generations and the HeapWalker. They provide the answers to two of the
	three questions you need to answer when searching for a memory leak: what, where, and why.

	<p><h3>Q: And what does generations tell you?</h3>
	<p>A: Generations is a very clever, very simple idea though it can be a
	bit tricky to understand at first. To understand generations you first
	have to understand how objects age. An object's age is determined by
	the number of garbage collections (GC) it has survived. Since most objects
	never survive more than a few microseconds, they rarely get very old.
	So you may have a handful of different ages for each class. Now let's
	say you create a cache of constant values that you initialize at the
	start of an application. These objects will survive every GC and
	consequently be very old. However you will still only have a handful
	of different ages for those objects. Even in a cache where objects are
	moved in and out on a regular basis you will most likely only have a
	handful of ages. Objects that are constantly leaking will have a large
	number of different ages.

	<p>So as you can see, the difference between
	objects that leak and objects that don't will most likely show up in
	the number of different ages or generations. The key is, once your
	application starts producing leaking objects it never stops. The
	result is that the leaking class will live in an ever increasing number of
	generations. So not only will the number be large, it will also be
	growing continuously. So this measurement is a really cool way to pick
	off this type of object leak.

	<p><h3>Q: Do you have a quick example that could help us better understand
	generations?</h3>
	<p>A: Sure, let's say your program allocates three instances of class
	Foo when the program starts and then it never allocates any more Foo
	objects. And it holds references to those three instances forever.
	Now let's say we look at the state of the application after the
	garbage collector has run 500 times. What is the generations value for
	the Foo class? The answer is 1 and it will stay 1. Now let's say that
	you also continuously create objects of class Bar that leak throughout the lifetime
	of the application. The generations value for class Bar will most
	likely be 500 and it will always be increasing.

	<p><h3>Q: So generations helps you identify "what" objects were leaking. What
	about "where" and "why"?</h3>
	<p>A: There are two things the NetBeans Profiler provides for that.
	First, during memory profiling it will show you which method allocated
	an object. Sometimes just knowing where a leaking object was
	allocated is enough of a clue to let you figure out why it has not
	been garbage collected. But the answer to "where" the object is
	leaking can often be far away from where it is being created. This is
	one factor that makes finding leaks so challenging. This is where
	the NetBeans HeapWalker comes into play.

	<p><h3>Q: How does the NetBeans HeapWalker help?</h3>
	<p>A: The JVM's HPROF agent is the original heap profiler. When you have it enabled it
	will produce a complete picture of everything that is in your Java
	heap space. The NetBeans HeapWalker uses the binary output from HPROF to
	reconstruct a view of memory. With the NetBeans HeapWalker you can perform a visual
	inspection of everything in that reconstructed view. The problem here
	is that even for a trivial application the heap can contain a very
	large number of objects. Finding a particular set of leaking objects in a heap
	is like looking for a needle in a haystack so you really need to have
	other bits of information to help you direct your search. So if we
	combine the information culled from generations with the HeapWalker,
	we can zero in on a suspected leak.

	<p>Once you've got an instance of the leaking class selected in the HeapWalker,
	the HeapWalker can find the shortest path from that object to a GC root. Chances
	are pretty good that when we do that we will find a domain object that is either an
	implied collection or contains a collection that is responsible for
	causing the leak. Now this still doesn't answer the question of "why" but
	even getting this far is a huge step in the diagnostic process.

	<p><h3>Q: Can you tell us about how you've used the tools?</h3>
	<p>A: I've been anxiously awaiting the arrival of a stable
	version of this tool so I can put it through its paces. The
	M7 milestone is stable enough to fit that criteria. Before I use
	a tool in a live situation I want to be able to understand how to most
	effectively apply it. So I maintain a number of applications that leak
	in a couple of different ways. I've used M7 to diagnose the leaks in
	these applications. So far the results look very promising in that
	I've consistently been able to pick out signs of the leak very very
	quickly. It was this experience that lead me to include the tool in my
	performance tuning course even though it (version 6.0 of NetBeans) is still being
	baked.

	<p><h3>Q: How is the NetBeans Profiler being used in your training class?</h3>
	<p>A: Again this is all very early stuff so the first introduction was
	gentle. However the impact of the tool in the heap tuning section of
	the course was dramatic. Since performance tuning is mostly about
	getting used to looking at the output from tools and instrumentation
	there is quite a bit of emphasis on solving problems. One of the
	exercises is particularly nasty. It contains a whole bunch of well
	hidden problems that closely resemble stuff I see in the field. The
	exercise is free form in that anything goes. They can use any tool
	they like or even rewrite the entire application.

	<p>Everyone decided to
	use NetBeans to diagnose the memory leaks and the results were
	outstanding. This group managed to find leaks much faster and with far
	less difficulties than any group that had previously taken the course.
	It was very interesting to watch and I have started to use what I've
	learned during that session to restructure that portion of the course.

	<p><h3>Q: Starting with Milestone 8 of NetBeans 6.0, the Profiler will be
	included with the standard IDE installation. You will no longer need
	to do a separate download and installation. How does that sound to you?</h3>
	<p>A: The install of the NetBeans Profiler was pretty trivial to begin with but
	anything to make it easier is always good news.

	<p><h3>Q: Are there any features you would like to see added to the NetBeans Profiler?</h3>
	<p>I think it goes without saying that there are always going to be times
	when you wish a tool could do this or that so yes, there are a number of
	things that I'd like to see included in the NetBeans Profiler. However I'd like
	to focus on one large feature that I think would be most useful, the
	ability to analyze information being reported upon by the garbage
	collector. You can get this information using the JVM's -verbose:gc flag but as
	you can imagine, the information is quite cryptic. It also requires one
	to do quite a few calculations to extract useful information from these
	logs and there are currently only a handful of tools with this
	capability. The existing tools leave a lot of information on the table.
	They also are standalone so there is some analysis that is either
	extremely difficult or just impossible to obtain.

	<p>For example, if you could combine
	the GC logging information with an execution profile all of a sudden you
	have the ability to zero in on areas of your application that are
	responsible for a lot of object churn. As we start to run our
	applications on more and more cores, applications will be able to create
	more garbage at a much faster rate. This will put more pressure on the
	garbage collector which means that being able to identify loci of object
	churn is going to become increasingly more important.


	<br style="clear:both;" />
	<!-- ======================================================================================= -->

	<h2><a name="moreinfo"></a>Resources</h2>
	<p>For more information about using the NetBeans Profiler, see the following resources:
	</p>
	<ul>
	<li><a href="https://netbeans.org/features/java/profiler.html">Profiler Overview</a></li>
	<li><a href="http://profiler.netbeans.org/docs/help/5.5/getting_started.html">Profiler Basics</a></li>
	<li><a href="https://netbeans.org/kb/55/profiler-tutorial.html">Profiler Tutorial</a></li>
	<li><a href="http://profiler.netbeans.org/">Profiler project home page</a></li>
	</ul>

	</body>
	</html>