UnsupportedSpecializationException and unsupported(.) methods
christian.humer at gmail.com
Mon Jun 8 22:14:06 UTC 2015
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
- Christian Humer
"Stefan Marr" <java at stefan-marr.de> wrote:
> 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 + “: " +
> I was thinking that perhaps the unsupported(.) methods that the DSL generates
> and the ones that are in SpecializationNode.java could use a
> Another workaround is to degrade the error message. One might also perhaps
> create it lazily if the getter isn’t final.
> Best regards
> Stefan Marr
> Johannes Kepler Universität Linz
More information about the graal-dev