Update Report Truffle 0.33 to 1.0.0-rc5

[Stefan Marr]

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/