title: Can JVM omit short-lived objects creation so I can do refactoring without hurting performance?
body: <p>Sometimes during the course of an algorithm we need to compute or simply store several values that depend on each other or don't make any sense apart from one another.</p>
  
  <p>Just as a (quite nonsensical, but what matters, simple) example lets find two distinct values in an <code>int[]</code> that are closest to the number <code>3</code>:</p>
  
  <pre><code>int a = values[0];
  int b = values[1];
  for (int value : values) {
      int distance = Math.abs(value-3);
      if (value != b) {
          if (distance &lt; Math.abs(a-3) ) {
              a = value;
          }
      }
      if (value != a) {
          if (distance &lt; Math.abs(b-3) ) {
              b = value;
          }
      }        
  }
  takeSausageSliceBetween(a, b);
  </code></pre>
  
  <p>We can't just make methods <code>computeA()</code> and <code>computeB()</code> in the same class because computations for <code>a</code> and <code>b</code> are interdepentant. So computing <code>a</code> and <code>b</code> is just asking to be refactored into a separate class:</p>
  
  <pre><code>class DistinctNumbersNearestTo3 {
      final int a;
      final int b;
      DistinctNumbersNearestTo3(int[] values) {
          // same algorithm
      }
  }
  </code></pre>
  
  <p>so the higher level code becomes nice and clear:</p>
  
  <pre><code>DistinctNumbersNearestTo3 nearest = new DistinctNumbersNearestTo3(values);
  takeSausageSliceBetween(nearest.a, nearest.b);
  // nearest never leaves the method it was declared in
  </code></pre>
  
  <p>However (please correct me if I'm wrong) it introduces, at least for some levels of optimisation, an instantiation and then garbage-collecting (just from eden, but anyway) of a new object just for the sake of being clear with your code. And also looking for int in stack turns into looking for an object in heap. </p>
  
  <p><strong>Question here is:</strong> Is JVM smart enough to eventually optimize the refactored code to operate just as the unrefactored code?</p>
  
  <p>Another case where I'd like to bunch together several variables into a new object just for cleaner code is when I want to refactor a long method <code>a()</code> into several new methods by introducing a new class <code>C</code> which holds data specific to <code>a()</code>'s invocation and therefore contains those several new methods to operate on that data. I stumbled upon such case when implementing a class that represents a set of chains to which we can add new links (pairs of nodes) therefore extending an existing chain, combining two chains together into one, or creating a new chain of two nodes. Lets discuss that particular class just for some perspective:</p>
  
  <pre><code>public class SetOfChains {
      List&lt;List&lt;Node&gt;&gt; chains;
      public void addLink(Node a, Node b) {
          // Very long method that mutates field this.chains. Needs refactoring.
      }
  }
  </code></pre>
  
  <p>To properly split <code>addLink</code> into several methods of <code>SetOfChains</code>, each of those new methods would have to have a lot of parameters, because there is data specific to <code>addLink()</code> invocation that is needed on every step of <code>addLink()</code>. Saving that data to dedicated fields of <code>SetOfChains</code> would as well be possible but smelly and inexpressive (because again it only makes sense during the method invocation), so obviously I create a new inner class to hold that data in its fields and do all the algorithm steps, mutating outer field <code>chains</code> as the unrefactored <code>addLink()</code> does:</p>
  
  <pre><code>class SetOfChains{
      List&lt;List&lt;Node&gt;&gt; chains;
      void addLink(Node a, Node b) {
        new LinkAddition(a,b).compute();
      }
      class LinkAddiditon { // Instances never leave addLink()'s scope
          private final Something bunch, of, common, fields;
          compute() {
              this.properly();
              this.isolated();
              this.steps();
              this.of();
              this.the();
              this.refactored();
              this.method();
          }
          // There be code for the properly isolated steps...
      }
  </code></pre>
  
  <p>But since fuctionally that is equivalent to having my old long unrefactored <code>addLink()</code>, can JVM make the resulting instructions to be as optimal as in the unrefactored case, as if there weren't any <code>LinkAddition</code> objects?</p>
  
  <p><strong>So, to draw the bottom line under that wall of text:</strong> If I strive for easy to understand code by extracting data and methods to new <em>classes</em> rather than methods, does it necessarily introduce a decrease in performance?</p>
  
  <p>And do I understand correctly that the described cases are exactly what <a href="http://en.wikipedia.org/wiki/Escape_analysis" rel="nofollow">escape analysis</a> is about?</p>