Update Report Truffle 0.33 to 1.0.0-rc5
Martin Entlicher
Martin.Entlicher at oracle.com
Mon Sep 3 13:55:31 UTC 2018
Thanks Stefan, I'm adding few comments...
On 3.9.2018 12:12, Christian Humer wrote:
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_truffle_commit_96253f73ee6243cd15222a0eae095b0e00620b36&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=09ltJt7X52_DneVnLAaI8A-bLVimP49Yj7dX3LCJmeE&e=>
>
> 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.
>
> > ## 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_truffle_commit_d448d9c2af94c7f9d771139123d96209a10361e1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=jJZq07yBR72L0SNhdgBMGW2nYw7ssKjXprg8wpX76GE&e=>
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.
> >
> > 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.
If you have SourceElement for the tag, then the only difference from the
existing prepareStepInto/Over(StepConfig stepConfig) is a Thread. But it
looks a bit strange to me to submit steps from SuspendedEvent into other
threads. If we add API for this, it will likely be the
DebuggerSession.suspend(Thread t) (which is package-private now), or
something similar. In general, when pausing different threads, you might
not have any SuspendedEvent. I can imagine that the suspend will take
SourceElement(s) as an argument.
However, where do you find the Thread from, to enter the async call? It
can also be the current thread (in case of JavaScript, for instance).
There can also be several async calls scheduled.
> 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. Expression debugging is not used much in
practice yet, but we could consider adding a way to specify it precisely.
Thanks,
Martin
>
> > 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_blob_master_truffle_docs_TCK.md&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=majCk8pHl46R4s4bZ6ypcZALpYfzZFV-7NksikJ9Igc&e=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_tree_master_sdk_src_org.graalvm.launcher_src_org_graalvm_launcher&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=Wkar-2S59ocOahs0aS7nddnSzmHnYptXEzKLl2LMyyI&e=>
> 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
> <mailto: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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_truffle_commit_96253f73ee6243cd15222a0eae095b0e00620b36&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=09ltJt7X52_DneVnLAaI8A-bLVimP49Yj7dX3LCJmeE&e=>
>
> ## 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_truffle_commit_d448d9c2af94c7f9d771139123d96209a10361e1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=jJZq07yBR72L0SNhdgBMGW2nYw7ssKjXprg8wpX76GE&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_truffle_commit_7689d6f383621959d357dfe492bcee85ae3eb466&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=p4JIkUM9sD1_II3VFhZjBsKWI_CWWCzbt9_GlLTijs4&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_truffle_commit_3c68e3dcffb3beab3e537ce5ac8e61a78c6b449d&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=bfq7I3M89YWEy1ZgK_C8fgeGIZquh84R7ZDLqAav_qQ&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_SOMns_pull_266_commits_7c21cda8d69ac479dfa0d838061a049fb02311ce&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=ulHatiG31OpIKhOOV4hUgogv_kAmxcJ6C1_XM5nDcck&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smarr_SOMns_pull_266&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=q2b1kI4VUAiY1l50yHoUsTL-hERzkGyNptvS1eyYABM&e=>
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> School of Computing, University of Kent
> http://stefan-marr.de/research/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__stefan-2Dmarr.de_research_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=FzZzwOyOcPxetxP6_0ByJLDDX0dCB48NkqDa6md_Ds8&m=c9AUdQODdD5E7lE_Ry_QkbaVwBbFXU6pnRYA-SdpoHQ&s=MiA5IWzS5G0bSY4JLmsbZXS75gzBZXlLYsmEO8uaJkc&e=>
>
>
More information about the graal-dev
mailing list