UnsupportedSpecializationException and unsupported(.) methods

[Christian Humer]

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?

Thanks.


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