UnsupportedSpecializationException and unsupported(.) methods

[Stefan Marr]

Hi Christian:

> On 09 Jun 2015, at 12:57, christian.humer at gmail.com wrote:
> 
> 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.

My workaround was to hack UnsupportedSpecializationException ;)

> 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.

Sounds good. This makes it probably also more robust in case people use UnsupportedSpecializationException directly. (think I saw references to it in simple language)

Thanks
Stefan

-- 
Stefan Marr
Johannes Kepler Universität Linz
http://stefan-marr.de/research/