Again Trouble with Non-local Returns

Andreas Woess andreas.woess at jku.at
Thu May 8 02:59:15 UTC 2014


(my bad, I thought a "git checkout master" in core-lib would do, too.
thanks)

I couldn't tell for sure now, but the deoptimization is likely coming
from an UnexpectedResultException. Anyway, the actual problem is
another. You can observe it when you add these two options
-Dtruffle.TraceRewrites=true -Dtruffle.DetailedRewriteReasons=true:
We see a ValueNonePrimGenericNode that constantly rewrites itself to
ValueNonePrimGenericNode (sic). Obviously, there's something with this.
On top of it all, the actual value is an SBlock, so we don't get an
UnsupportedSpecializationException, too. But what are we even doing in
the generic node, if we only ever saw SBlock (the only supported type)?
Let's have a look the code:
> public void executeEvaluatedVoid(VirtualFrame frameValue, Object
> receiverValueEvaluated) {
>     Object[] receiverValue;
>     try {
>         receiverValue = TYPES.expectObjectArray(receiverValueEvaluated);
>     } catch (UnexpectedResultException ex) {
>         executeAndSpecialize0(2, frameValue, ex.getResult(), "Expected
> receiverValue instanceof Object[]");
>         return;
>     }
>     this.executePreEvaluated(frameValue, receiverValue);
> }
For some reason, the DSL has picked executePreEvaluated here and
stubbornly tries to cast the receiver to its parameter type, Object[].
My dumb and easy quickfix was to rename
UnaryExpressionNode.executePreEvaluated to something that doesn't start
with "execute". After:
> public void executeEvaluatedVoid(VirtualFrame frameValue, Object
> receiverValueEvaluated) {
>     Object receiverValue = receiverValueEvaluated;
>     this.executeEvaluated(frameValue, receiverValue);
> }
I'll assign a bug to Christian Humer.

- andreas

On 2014-05-08 02:31, Stefan Marr wrote:
> Is the core-lib sub module updated? git submodules update or something
> like that should do it.
>
> On Thursday, May 8, 2014, Andreas Woess <andreas.woess at jku.at
> <mailto:andreas.woess at jku.at>> wrote:
>
>     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