UnsupportedSpecializationException and unsupported(.) methods

[Stefan Marr]

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/