UnsupportedSpecializationException and unsupported(.) methods
java at stefan-marr.de
Tue Jun 9 11:32:16 UTC 2015
> 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)
Johannes Kepler Universität Linz
More information about the graal-dev