TaggedArrays (Proposal)

[Rémi Forax]

On 07/07/2012 04:54 AM, Mark Roos wrote:
> Hi Rémi,  you mention
> And now the trick, there is a nice way (several in fact) to explain to
> the JIT
> that even if the bytecode contains tests, if the variable contains
> effectively an int,
> it's a good idea to remove them.
>
> Ok,  in Smalltalk there are some methods which are usually integer ops
> so its easy to determine vars that are likely integer.  I have slots in
> the stack reserved for just this idea.
>
> So if I have a pair of slots A and B where A would be the integer from 
> and B the reference.
> Would I test B to be null and if so do an integer op on A?

yes, that the basic idea.

>
> So plese point me at the bytecode tricks that make the test go away.

It's not a bytecode trick, it's a JIT trick.
The VM profiles jump instruction like 'if' to know which branch is 
taken, and
doesn't generate code but a deoptimization code if a branch is never taken.
So the generator of a backend will generate a code like this for a + 1:

   int r1 = ...
   Object o1 = ...
   if (o1 == null) {
      r2 = r1 + 1
      o2 = null
   } else {
      r2 = 0
      o2 = invokedynamic + o1, 1
   }

   if (o2 == null) {  // next instruction
   ...
   } else { ...
   ...

and because o1 is never null, the JIT will generate

jne a_deoptimization_code
inc r2

also because the JIT propagates null value aggressively, the jump can 
also disappear because
there is perhaps already another check before, by example, the check o2 
== null will
be removed here.

So the idea is to consider that if a variable can store an int, you 
should use two variables in the bytecode,
so result of an operation will be spilled into two variables instead of 
using the stack.
I call this idea, split-path and this is really effective, the main 
drawback is that the generated bytecode size
is big compared to the code of the generated assembler so the JIT may 
decide to not inline something
that it should.

You have also to figure out how to get two return values from a method call,
but exceptions are your best friend here.

>
> regards
> mark

rgds,
Rémi