Update Report Truffle 0.33 to 1.0.0-rc5

[Christian Humer]

Hi Stefan,

Thanks a lot for the report. I've added a few notes.

> ## Java Run-Time condition for Breakpoints
>
> While guest-language conditions have been supported from early on,
> I do need breakpoint conditions on the interpreter level, and therefore
got
> the support for a simple condition in Java, too:
>
https://github.com/smarr/truffle/commit/96253f73ee6243cd15222a0eae095b0e00620b36

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.

> ## Advanced Breakpointing and Stepping
>
> I use tags for advance breakpoints, for instance on thread creation, on
joining
> a fork join task, or sending an actor message:
>
https://github.com/smarr/truffle/commit/d448d9c2af94c7f9d771139123d96209a10361e1
>
> I use a stepping strategy to step until the next node with a given tag.
> This is very useful when I can't statically determine the target of a
specific
> stepping operation, but I know that it has to be of a specific kind.
> I use this for instance to trigger a breakpoint when an async.
message/callback
> is starting to execute, or just before a method returns that is going to
be
> used to resolve a promise. Highly useful to step through async. code.

We will likely need such a feature for async/wait breakpoints in Chrome
Inspector support as well.
(cc)Martin, please make sure we also support Stefans use-cases when we work
on this.

> One problem with the notion of wrappers is that it is rather complicated
to ensure that they always have the right type.

This is a long time issue we also had with the old instrumentation API.
The general rule of thumb is to generate a new wrapper for all nodes that
declare new public API like execute methods or meta-data accessors.

> The language interop support is something I haven't invested much time in
yet.
> So, the fact that the old testing infrastructure is gone is somewhat
> unfortunate, because this means my interop support is now untested.

Please consider adopting the new TCK:
https://github.com/oracle/graal/blob/master/truffle/docs/TCK.md
It is more flexible as it allows to enumerate all language constructs to be
tested.

> Adopting the basic bits of the Graal SDK, and switching away from
PolyglotEngine
> was comparably simple. Though, I didn't build a full SDK-style launcher.

FYI: You may also use our language launcher framework here:
https://github.com/oracle/graal/tree/master/sdk/src/org.graalvm.launcher/src/org/graalvm/launcher
It only depends on the SDK and language command line options are fully
customizable. It adds commands flags like --jvm or --polyglot.

- Christian Humer



On Mon, Sep 3, 2018 at 12:00 AM Stefan Marr <java at stefan-marr.de> wrote:

> Hi:
>
> Thought I share same thoughts on my latest Truffle update.
>
> It took me quite a while to update, because some of my patches to Truffle
> needed
> major revisions or reimplementation to account for some new features in
> Truffle.
>
> As you may know, I have been maintaining patches on top of Truffle
> for the last three years. They revolve mostly around support for more
> dynamic
> instrumentation and advanced debugging features.
>
>
> # Now unnecessary patches
>
> The good news is that I was finally able to drop some custom patches.
>
> ## Node.notifyInserted(.)
>
> This method is apparently already there since 0.27, but I didn't notice
> before.
> It allows me to drop one of my earliest patches to insert wrapper nodes for
> newly inserted subtrees. Thank you.
>
> ## InstrumentableNode.hasTag(.)
>
> This new interface and its hasTag(.) method make it unnecessary for me to
> add
> an isTaggedWith(.,.) method to Instrument.
>
> ## Thread-safety checks
>
> I used to remove assertions in the PolyglotEngine that made sure it was
> only
> used from a specific thread. Seems like this idea was dropped, which means
> I
> don't need to hack out these checks any more :)
>
>
> # Still maintained patches
>
> However, I still maintain a few patches, I consider more generally useful.
> So, perhaps the ideas underlying them could be picked up at some point.
>
> ## Java Run-Time condition for Breakpoints
>
> While guest-language conditions have been supported from early on,
> I do need breakpoint conditions on the interpreter level, and therefore got
> the support for a simple condition in Java, too:
>
> https://github.com/smarr/truffle/commit/96253f73ee6243cd15222a0eae095b0e00620b36
>
> ## Advanced Breakpointing and Stepping
>
> I use tags for advance breakpoints, for instance on thread creation, on
> joining
> a fork join task, or sending an actor message:
>
> https://github.com/smarr/truffle/commit/d448d9c2af94c7f9d771139123d96209a10361e1
>
> I use a stepping strategy to step until the next node with a given tag.
> This is very useful when I can't statically determine the target of a
> specific
> stepping operation, but I know that it has to be of a specific kind.
> I use this for instance to trigger a breakpoint when an async.
> message/callback
> is starting to execute, or just before a method returns that is going to be
> used to resolve a promise. Highly useful to step through async. code.
>
>
> https://github.com/smarr/truffle/commit/7689d6f383621959d357dfe492bcee85ae3eb466
>
> 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
>
> These last three points where the major elements that needed revision for
> my Truffle updated, because the related Truffle code was changed
> substantially,
> which means I needed to completely reimplement my patches.
>
>
> # Other notes on the update
>
> Beside rewriting my custom patches, the change that required most work was
> likely going from @Instrumentable to @GenerateWrapper:
> https://github.com/smarr/SOMns/pull/266/commits/7c21cda8d69ac479dfa0d838061a049fb02311ce
>
> To make this work nicely, I had to change a couple of things around.
> One problem with the notion of wrappers is that it is rather complicated to
> ensure that they always have the right type.
> The type is constrained on the one side by the field containing the child
> node,
> and on the other side, by the node that is actually wrapped.
> So, there is a tension between having few very general wrappers, and the
> specifics one might want to use in some node.
> It requires quite a bit of care to have a more specific field type for the
> child node and make everything work out correctly.
> Not sure what one could do about this, but it sounds like something that
> would deserve some general guideline and recommendation about how to
> structure
> the tree of nodes one has in a language. Though, I don't really know what
> one
> would recommend. I dealt with my nodes mostly on a case-by-case basis.
>
> The language interop support is something I haven't invested much time in
> yet.
> So, the fact that the old testing infrastructure is gone is somewhat
> unfortunate, because this means my interop support is now untested.
>
> Adopting the basic bits of the Graal SDK, and switching away from
> PolyglotEngine
> was comparably simple. Though, I didn't build a full SDK-style launcher.
>
> In an other email, I mentioned some compilation issues, but I suppose
> those are mostly Graal issues.
>
> For the curious, the SOMns PR for the update is here:
> https://github.com/smarr/SOMns/pull/266
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
>
>
>