Recent Truffle DSL changes.

[Stefan Marr]

Hi Christian:

While trying to debug the problem I am seeing, I noticed something I haven’t noticed before, and would like to hear whether it is by design or whether I can do something about it.

In my node to read local variables, I got specializations for the different slot types:

https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/nodes/LocalVariableNode.java#L56-L76

However, now it looks like the generated code goes through all specializations in a top to bottom approach, until the correct one is found.
And this involves creating new nodes, and leads eventually to the ‘concurrency’ issue I was seeing.

For me the question now is whether I can avoid all the ‘unnecessary’ trial and error somehow. I was experimenting with a guard on the slot kind that tests the slot type specifically to be boolean, long, or double. However, since I need the rewriteOn = slot-type-exception, the DSL now tells me that the different specializations are not compatible to each other.

I was experimenting also with ‘contains’, but that does not seem to make a difference.

So, I was wondering whether the brute-force approaches is intended, or whether there is an easy way around by for instance telling the DSL that doObject is the next general thing after doBool, doLong, or doDouble respectively.

Thanks
Stefan




On 18 Sep 2014, at 11:12, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Christian:
> 
> On 18 Sep 2014, at 00:05, Christian Humer <christian.humer at gmail.com> wrote:
> 
>> Regarding the thread-safety issues. Yes polymorphic rewrites are not yet thread-safe. But they were also not thread-safe in the old version. So you might have been just lucky.
>> However it is straight forward to make them thread-safe. You just have to wrap every replace in DSLShare into a closure and call atomic on the node that is currently in the AST.
>> I've attached a patch. Let me know if that works for you. So I can push it tomorrow. (Had no time to verify it yet) 
> 
> Have only tested it briefly, but there is still an issue with a node that doesn’t have a parent yet.
> The Eclipse and the JVM are unfortunately rather uncooperative. Debugging this isn’t exactly easy, because for half of the objects Eclipse refuses to give me any information.
> Is this a known issue? I set the debugger to suspend the VM once an illegal state exception is hit. That doesn’t seem to be a good idea.
> 
> Will try to look into it later today.
> 
> Thanks
> Stefan
> 
> -- 
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
> 
> 
> 

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/