compiled leaf method vs. inlined method bounds check

[Gilles Duboscq]

Can you maybe show us the snippets you used and how you ran them?
The second scenario you describe usually happen if an
ArrayIndexOutOfBoundsException has already been thrown at the array access
you're looking at.
When compiling an array access, Graal will look at the profile and if it
shows that exceptions are thrown there, it will compile in the exception
branch (in your case the exception branch ends up into an other deopt for
some reason). If profiling shows no exception has been thrown there, it
will leave out the exception branch and will only place a which deoptimizes
in case an exception needs to be thrown.

This should have nothing to do with inlining. When doings tests about that,
be carefull not to pollute the profile for the second test with the first
one.
You can change the bahviour of graal reagrding these things using
the UseExceptionProbabilityForOperations flag.

-Gilles


On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau <tom.deneau at amd.com> wrote:

> I've noticed that if the graph I am compiling is simply a leaf method
> which accesses an array, the target of a failing bounds check is a
> DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile
>
> But if the method that is accessing the array is being inlined into
> another method, the target of the failing bounds check is a ForeignCall to
> createOutOfBoundsException followed by a branch to a DeoptimizeNode with
> reason=NotCompiledExceptionHandler, action=InvalidateRecompile.
>
> Can someone explain this difference?
>
> -- Tom
>
>
>