UnsupportedSpecializationException and unsupported(.) methods

Christian Humer christian.humer at gmail.com
Mon Jun 8 22:14:06 UTC 2015

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?


- Christian Humer
"Stefan Marr" <java at stefan-marr.de> wrote:
> Hi:
> I think I mentioned earlier, somewhere, that I was seeing strange issues in 
> the PE.
> Now I was looking into optimizing performance of SOMns and see again 
> ConcurrentHashMap and other stuff being dragged into compilation units.
> The root cause is the constructor of UnsupportedSpecializationException and 
> probably the informative error message that is constructed with something 
> like: “Unexpected values provided for “ + node + “: " + 
> Arrays.toString(suppliedValues)
> I was thinking that perhaps the unsupported(.) methods that the DSL generates 
> and the ones that are in SpecializationNode.java could use a 
> transferToInterpreter()?
> Another workaround is to degrade the error message. One might also perhaps 
> create it lazily if the getter isn’t final.
> Best regards
> Stefan
> --
> Stefan Marr
> Johannes Kepler Universität Linz
> http://stefan-marr.de/research/

More information about the graal-dev mailing list