Update Report Truffle 0.33 to 1.0.0-rc5

[Stefan Marr]

Hi Martin,
Hi Christian:

> On 3 Sep 2018, at 14:55, Martin Entlicher <martin.entlicher at oracle.com> wrote:
> 
>> > ## Java Run-Time condition for Breakpoints
>> 
>> I remember discussing this long time ago. That patch exposes PE to the debugging API user. 
>> I wanted to avoid this to reduce complexity for debugging protocol implementers.
>> I think it would be best to discuss some use-cases, to find out whether a generic feature like this really is necessary.
> 
> This can be a way how to extend the debugging logic. But it looks strange to me, that SimpleCondition.evaluate() does not take any context information. I’m also curious about the use-cases and about how a typical Java condition might look like.

For me this is the simplest solution to figure out whether a method is activated via an asynchronous message send or just via normal invocation.
For that test, I do not need any context, and it is the only thing I am doing with it.

I don’t have a good other use case for it.
The main reason I listed it, is because of the seeming asymmetry in the API.
You can do something at the guest language level, but not easily at the interpreter level.

But, this is really a rather trivial patch, so, I don’t think it is necessary to go upstream.

>> > I use tags for advance breakpoints, for instance on thread creation, on joining
> 
> We use SourceElement enum to abstract the Tag and to limit the set of tags that can be used in debugging. So far we support StatementTag and ExpressionTag only. Use of a non-standard tag would limit debugging to those languages that provide such tag.
> It might be easier to patch just the SourceElement with your additional tags.

My tags are far from general, so, I didn’t want to move them into the enum.
And yes, they are not just language specific, but perhaps even framework/library specific.

One possible way of decoupling is described here: http://stefan-marr.de/papers/dls-marr-et-al-concurrency-agnostic-protocol-for-debugging/
I’d think that the basic idea would also neatly apply to Truffle.
We already do advertise what features a language provides, we just don’t have the Truffle debugger “configureable” from the language yet.
Perhaps relevant to know: I am using custom breakpoint-trigger nodes in my language.
So, there is a node that is only executed in case of a breakpoint, and then the normal Truffle debugger mechanisms are used. (The node is tagged to always suspend execution.)

While this exposes the debugger to the language, the debugger itself is still independent from the language.
I suppose it could also be solved differently, but then I would be less free in how I design my nodes.
So, I chose this way around. (But, I can understand that this is likely not your preferred solution.)

>> > I use a stepping strategy to step until the next node with a given tag.
> 
> If you have SourceElement for the tag, then the only difference from the existing prepareStepInto/Over(StepConfig stepConfig) is a Thread.

Ehm, I am not sure what you mean. “Step to next node with given tag” is sufficiently different from step into/over.

> But it looks a bit strange to me to submit steps from SuspendedEvent into other threads.

I don’t submit steps into other threads.
A suspended event only instructs the current thread on how to proceed.


> > Much of this depends on being able to set breakpoints precisely (with line, column, length, and tag).
> > So, I also needed to add support for that. Currently, Truffle tries to find a
> > best match, perhaps based on column and line, which isn't precise enough for
> > my use case:
> >
> > https://github.com/smarr/truffle/commit/3c68e3dcffb3beab3e537ce5ac8e61a78c6b449d
> 
> When debugging expressions it happens that there are sections with the same tag starting or ending on the same position. The section length is a way to distinguish that.

Yes. My understanding is that the current algorithm can find the perfect match, but then still end up using some other source section, which also somewhat fits, but more fuzzily. This didn’t work for me.
So, I added a step that identifies the perfect match (i.e., matching line, column, length) and disregards other matches afterwards.

Best regards
Stefan

-- 
Stefan Marr
School of Computing, University of Kent
http://stefan-marr.de/research/