Recent Truffle DSL changes.

[Wei Zhang]

Hi Christian,

I finally merged with graal-0.5... It was very smooth.
But I did run into one issue.

https://bitbucket.org/ssllab/zippy/src/cd9ba144cc20c30181f5314584e148ea38e1fa45/graal/edu.uci.python.nodes/src/edu/uci/python/nodes/expression/BinaryArithmeticNode.java?at=default
After merge in the AddNode of ZipPy, if I have multiple consecutive
specializations with the rewriteOn attribute specified to
ArithmeticException.class, the DSL processor complains.
I currently disabled rewriteOn exception for doIntBoolean() and
doBooleanInt in AddNode to get around the error.
If I put them back on I get the following error msg:
This specialiation is not a valid exceptional rewrite target for
doBooleanInt(boolean, int). To fix this make doInteger(int, int)
compatible to doBooleanInt(boolean, int) or remove the exceptional
rewrite.

Any though?

Thanks,

On Thu, Sep 18, 2014 at 10:00 AM, Stefan Marr <java at stefan-marr.de> wrote:
> Hi Christian:
>
> On 18 Sep 2014, at 18:09, Christian Humer <christian.humer at gmail.com> wrote:
>
>> Unfortunately there is no way to resolve this yet. But I am aware of that problem. We could do this if we declare a hint where to rewrite to next from all compatible specializations. Its on my TODO list.I already talked to Andreas a few weeks ago and we also should not use rewrite by exception for local variables. So we might invent a new pattern for that.
>
> Ok, I’ll keep it on my todo list as well.
>
>
>> Yes this needs to be done at specialization level. The DSL implementation does this on this level (with my patch). All the inline cache implementation need to do the same. This is why we currently expose the "atomic(Callable)" API. Also nodes should not be respecialized twice as you mentioned. Instead they should be copied.
>
> Will probably not get to making TruffleSOM thread-safe this week.
> But, I was wondering how the API could help me to know that I am doing something in a way I shouldn’t do it.
>
> How about adding a ReentrantLock object to the root node, removing the implicit lock acquisition from replace(), and instead putting an assertion on isHeldByCurrentThread() in there? I realize that it might be slightly inconvenient. But, it would make it explicit to the language implementer that one has to look out for those things.
> As a compromise, a replaceLocked(.) could be introduced.
> Generally, I would also prefer if the method names would tell me something about the concurrency properties.
>
> Another thing I was wondering about is whether some of those concepts in DSLShare could be promoted for general use. It kind of represents good standard practices, right?
> And even if one needs to step outside the DSL, I presume the general structuring and concepts would still help to implement custom things. I was thinking about the notion of ‘uninitialized’ and the find and rewrite helper methods, for instance.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>