Compiled call version seems to be slower

[Christian Thalinger]

On Thu, 2009-11-26 at 00:12 +0100, Ulf Zibis wrote:
> Am 23.11.2009 12:01, Christian Thalinger schrieb: 
> > On Sat, 2009-11-21 at 22:44 +0100, Ulf Zibis wrote:
> >   
> > > In my attached example -XX:+PrintAssembly outputs 2 versions for 
> > > sun.nio.cs.ext.EUC_TW_C_d_b_codeToBuffer4$Decoder::decodeArrayLoop.
> > > 
> > > The 1st one seems for call from compiled calling method, the 2nd for 
> > > call from byte code interpreter.
> > > Looking closer to the -XX:+PrintAssembly output, 1st version seems to
> > > be 
> > > slower, i.e. has more instructions in the loop code.
> > > 
> > > Additionally I'm wondering why the finally block is copy-and-pasted
> > > for 
> > > each separate return.
> > > Is that as disired ?
> > >     
> > 
> > I just had a quick glance at the code and it seems the second one has a
> > better register allocation, for whatever reason.  And maybe (would need
> > to look closer) basic block ordering is different.
> >   
> 
> Additional question:
> What does that mean in exact, that there are 2 little different
> compiler outputs for the same method?
> Which of the 2 would actually run?

Ahh, sorry, I misunderstood.  The two disassemblies are from the same
run, I thought these are two different runs.

Well, the first version seem to have been invalidated, for whatever
reason, and got recompiled.  A -XX:+PrintCompilation would probably tell
us.  And it's very likely that a second compile is different than the
first one (more profiling data, different inlining, ...).

-- Christian