UnsupportedSpecializationException and unsupported(.) methods

Stefan Marr java at stefan-marr.de
Tue Jun 9 11:32:16 UTC 2015

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)


Stefan Marr
Johannes Kepler Universität Linz

More information about the graal-dev mailing list