Recent Truffle DSL changes.

Stefan Marr java at
Thu Sep 18 17:00:40 UTC 2014

Hi Christian:

On 18 Sep 2014, at 18:09, Christian Humer <christian.humer at> 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 Marr
INRIA Lille - Nord Europe

More information about the graal-dev mailing list