UnsupportedSpecializationException and unsupported(.) methods

[christian.humer at gmail.com]

Hi Stefan,

Thanks for the detailed report.

This problem applies to nodes with a single specialization only. As a 
temporary workaround you can add another specialization or add a custom 
@Fallback specialization.

I've fixed this by:
1) Making the message computed lazily
2) Made the UnsupportedSpecializationException constructor a 
@TruffleBoundary.
3) Letting nodes with a single specialization speculate with a 
compilation final boolean that the unsupported branch is actually never 
reached.

So as a result unsupported should trigger a deopt if never reached and 
if it was reached the complex code is hidden behind a boundary.

Currently pushing. Should arrive soonish.
- Christian Humer




------ Original Message ------
From: "Stefan Marr" <java at stefan-marr.de>
To: "Christian Humer" <christian.humer at gmail.com>
Cc: graal-dev at openjdk.java.net
Sent: 09.06.2015 00:27:16
Subject: Re: UnsupportedSpecializationException and unsupported(.) 
methods

>Hi Christian:
>
>>  On 09 Jun 2015, at 00:14, Christian Humer <christian.humer at gmail.com> 
>>wrote:
>>
>>  Hi Stefan,
>>
>>  Unsupported should get called on the slow path only. Therefore the 
>>UnsupportedSpecializationException constructor should not end up in 
>>PE. Its entirely possible that I have missed a case. In which node did 
>>you see this problem occurring?
>
>I have multiple ‘incomplete’ nodes. The unsupported paths are never 
>taken, by construction however.
>
>One simple one is:
>
>public abstract class NewPrim extends BinaryExpressionNode {
>
>   protected static final boolean receiverIsArrayClass(final SClass 
>receiver) {
>     return receiver == Classes.arrayClass;
>   }
>
>   @Specialization(guards = "receiverIsArrayClass(receiver)")
>   public final SArray doSClass(final SClass receiver, final long 
>length) {
>     return new SArray(length);
>   }
>}
>
>Which is compiled by the DSL to:
>
>         @Override
>         public SArray executeSArray(VirtualFrame frameValue) {
>             SClass receiverValue_;
>             try {
>                 receiverValue_ = receiver_.executeSClass(frameValue);
>             } catch (UnexpectedResultException ex) {
>                 Object argumentValue = 
>argument_.executeGeneric(frameValue);
>                 throw unsupported(ex.getResult(), argumentValue);
>             }
>             long argumentValue_;
>             try {
>                 argumentValue_ = argument_.executeLong(frameValue);
>             } catch (UnexpectedResultException ex) {
>                 throw unsupported(receiverValue_, ex.getResult());
>             }
>             if ((NewPrim.receiverIsArrayClass(receiverValue_))) {
>                 return this.doSClass(receiverValue_, argumentValue_);
>             }
>             throw unsupported(receiverValue_, argumentValue_);
>         }
>
>
>At least one of the calls to `unsupported(.,.)` is becoming part of the 
>compilation unit, perhaps the last one.
>The call is done before the actual throw. And I guess, the 
>if/implicit-else isn’t PE-able or something.
>
>Either way, the constructor of UnsupportedSpecializationException 
>does’t contain a `neverPartOfCompilation()`, would probably be good to 
>make that explicit.
>
>Best regards
>Stefan
>
>--
>Stefan Marr
>Johannes Kepler Universität Linz
>http://stefan-marr.de/research/
>
>
>