Again Trouble with Non-local Returns

Andreas Woess andreas.woess at jku.at
Wed May 7 23:52:47 UTC 2014


Hi Stefan,

I'm having trouble running this. After adding
TestSuite/BasicInterpreterTests to the -cp, I get:
> Exception in thread "main" java.lang.RuntimeException: Recheck
> implementation, do we really need to convert here? and what's with the
> receiver?

- andreas

On 2014-05-07 23:23, Stefan Marr wrote:
> Dear all:
>
> I think, I might have identified one of the potential issues holding back TruffleSOM.
>
> A lucky guess let me to look into the performance of non-local returns once more.
>
> The key part of the micro benchmark looks like this:
>
>     first:  a = ( ^ self second: a )
>     second: a = ( ^ self third: a  )
>     third:  a = ( a value )
>     
>     nlr = (
>         self first: [^ 1]
>     )
>
> Meaning, the #nlr method catches the non-local return of the value 1 and returns to the caller.
>
> The main problem I am seeing is that one of the involved call targets is triggering uncommon traps again.
> Think, we had a similar issue a while back, but I didn’t notice any regressions around non-local returns, so, I presume its a slightly different case this time.
>
> The uncommon trap looks like this:
>
> Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::callRoot (Graal: installed code has no name)  (@0x0000000110318b2c) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 debug_id=0
> Uncommon trap   bci=0 pc=271682348, relative_pc=268, method=com.oracle.graal.truffle.OptimizedCallTarget.callRoot([Ljava/lang/Object;)Ljava/lang/Object;, debug_id=0
> No speculation
>
>
> To reproduce you can execute the following:
>
> git clone --recursive https://github.com/SOM-st/TruffleSOM.git
> cd TruffleSOM
> ant
> mx --vm server vm -XX:+UnlockDiagnosticVMOptions -XX:+TraceDeoptimization -Xbootclasspath/a:build/classes:libs/truffle.jar som.vm.Universe -cp Smalltalk Examples/Benchmarks/BenchmarkHarness.som NonLocalReturn 20 0 1000
>
>
> Any thoughts on the issue, could it be something in Graal?
>
> Thanks
> Stefan
>



More information about the graal-dev mailing list