title: short -> int -> long type promotion: is there any overhead?
body: <p>If, for example, I define method's return type/parameter as <code>char</code>, but both the caller and implementation actually immediately use it as an <code>int</code>, is there any overhead? If I understand correctly, the values on the stack are 32-bits aligned anyway, as are the 'registers' (I'm sorry, I'm not well versed in the byte code).</p>
  <p>A word of explanation: I am writing low-level code for parsing and formatting binary streams. I need a representation of a single bit, used when indexing the stream to read and update individual bits. This is Scala and I am using a value class, that is a construct erased at compile time to a chosen java primitive type. This means that methods defined as:</p>
  <pre><code>class Bit(val toInt :Int) extends AnyVal
  
  @inline def +=(bit :Bit) = ...
  @inline def +=(int :Int) = ...
  </code></pre>
  <p>clash with each other at compilation, because they are both <code>$plus$eq$(int)</code> in the byte code.
  There are obviously ways around it, chief of them naming the methods differently, but I'd prefer to avoid it in case it doesn't matter. An <code>int</code> was a natural choice for a bit representation as it is the result of any bitwise operation, so the 'conversion' from <code>word &gt;&gt; offset &amp; 1</code> to a <code>Bit</code> is a no-op and likewise, they can be dropped inside bitwise expressions without needing any, either. As you see, pretty fine grained stuff.</p>
  <p>I won't use a <code>boolean</code> as there doesn't seem to be any way around a conditional expression when converting to and from an <code>int</code>, but I thought about a <code>char</code>, which would be otherwise unused (i.e., there is no need for reading and writing a character, as they are much higher abstractions than I'm dealing with at this level).</p>
  <p>So, does throwing in <code>char</code>s into bitwise operations all the time affect things at all, or is it for example two orders of magnitude faster than a method call (as in the overhead of creating and popping an activation record)?</p>