Enhancing Insight to allow tracking of reads/writes of local variables

[JaroslavTulach]

• tracking reads/writes of local variables is a useful instrumentation technique
• let's enhance GraalVM Insight to provide support for that!
• one can specify not only roots, expressions and statements are instrumentation types, but also:

{
   reads: true,
   writes: true
}

• when such an instrumentation event occurs, it is possible to access the getNodeObject via ctx.attrs
• this would be useful for Enso in cooperation with Trace local variable read/write via Truffle instrumentation enso-org/enso#14540
• had to enhance InstrumentationTestLanguage with support for these tags, CCing @chumer

[JaroslavTulach]

@chumer please review the concept of my change. I'll polish it and provide some documentation then.

[chumer]

Can you describe what your use-case for this feature is?

Please note that reads and write tags for dynamic languages are typically not fully reliable, so they typically fall short of being useful. So I am curious what you are using them for.

[chumer]

Looks mostly good. Please also add a changelog entry to tools changelog.md.

[JaroslavTulach]

Can you describe what your use-case for this feature is?

• done in d13c394
• Enso use-case is described at Trace local variable read/write via Truffle instrumentation enso-org/enso#14540

Please note that reads and write tags for dynamic languages are typically not fully reliable

• What do you mean by "not fully reliable"?
• When the language exposes the WriteVariableTag and ReadVariableTag instrumentations
• I'd expect them to be reliable
• at least I don't see any problem implementing these instrumentations in Enso

[chumer]

• Enso use-case is described at Trace local variable read/write via Truffle instrumentation enso-org/enso#14540

I don't see the use-case there. What feature would you use this instrumentation for? Or how would you recommend your users to use it?

Please note that reads and write tags for dynamic languages are typically not fully reliable

• What do you mean by "not fully reliable"?

Implicit local reads and writes without a dedicated node won't be instrumented. For example reads from objects often happen implicitly as part of the semantics of other operations. This makes read/write instrumentation not really useful if you want to e.g. track side-effects of a method. This is why I asked for the use-case. It is possible that Enso actually does not do implicit reads/writes. JS certainly does, so instrumenting reads/writes won't actually instrument all reads/writes.

• When the language exposes the WriteVariableTag and ReadVariableTag instrumentations
• I'd expect them to be reliable
• at least I don't see any problem implementing these instrumentations in Enso

See above. Of course when the tags are specified the individual instrumentations are reliable, but incomplete.

[JaroslavTulach]

• Enso use-case is described at Trace local variable read/write via Truffle instrumentation enso-org/enso#14540

I don't see the use-case there. What feature would you use this instrumentation for? Or how would you recommend your users to use it?

• I wanted to describe a use-case without spelling out Enso, hence it may not be fully convincing
• Let's describe the real use-case

Enso Runtime Cache

• Enso is live coding environment
• while the user is live coding, the program (typically, but not necessarily the main function) is being executed again and again
• to speed such execution up Enso is using Truffle Instrumentation to observe the program execution and cache the computed values of local variables
• subsequent computation of the same program just reads the values from cache and skips any computation
• should some part of the program change
  • then the affected value is evicted from the cache
  • and thus computed again during next execution
• not only single value, but also all depending values are evicted from the cache
  • Enso is currently computing depending variables via static analysis
  • with proper reads/writes support we should be able to do that reactively in runtime
• so far we've been using custom tags for this mechanism
• however my hope is that with properly implemented ReadVariableTag and WriteVariableTag we'll be able to rely just on these standard tags
• right now Enso has its instrumentation written in Java
  • however I hope we'll be able to rely just on GraalVM Insight one day
  • that however means we need access to ReadVariableTag and WriteVariableTag from Insight
• that's why I created this PR

[chumer]

Why would you want to use instrumentation for that and not make this behavior part of the language? From what I understand caching is really a first-class citizen in Enso, no?

It also does not really translate across languages, because for example you cannot cache values in JS with read/write tags without changing JS semantics.

Instrumentation comes with all sorts of footprint overheads, that you typically don't care for debugging, but for language feature use-cases its not ideal. It typically is better to implement that directly in the language.

[JaroslavTulach]

Why would you want to use instrumentation for that and not make this behavior part of the language? From what I understand caching is really a first-class citizen in Enso, no?

• Not really: caching is only used when running in the IDE - not when running from the CLI
  • e.g. caching is not core language feature
  • rather caching is a tooling on top
• Hence I am glad I inherited such “separation of concerns” design

It also does not really translate across languages, because for example you cannot cache values in JS with read/write tags without changing JS semantics.

• Right, immutability of some kind is needed
  • either the language or APIs provide it, or the results are not "ideal"
  • certain parts of Enso are mutable - and they rather shall not be exposed in the IDE
• Enso has plans to integrate with Python
  • we hope we'll be able to use the same tooling
  • at least for "carefully selected" subset of Python APIs

Instrumentation comes with all sorts of footprint overheads, that you typically don't care for debugging, but for language feature use-cases its not ideal. It typically is better to implement that directly in the language.

• There is certainly an overhead when running in the IDE
• Alas, the instrumentation overhead is negligible part of that
• Btw. instrumentation overhead would decrease significantly
  • if we used GraalVM Insight instead of home made TruffleInstrument
  • because you forced me to write Insight so it partially evaluates well
  • while our home made instrument runs behind @TruffleBoundary

... able to rely ... on GraalVM Insight... means we need access to ReadVariableTag and WriteVariableTag

• If I ever want to use Insight, then I will really need it to support more than expressions, roots and statements
• Is that enough to justify Insight being extended with support for reads and writes tags?

[chumer]

I still would implement this as an embedding extension point for the language. I do not think this approach will work well for Python, because it is potentially side-effecting pretty much everywhere. We currently have no plan to implement READ/WRITE instrumentation there (to my knowledge).

Btw. instrumentation overhead would decrease significantly
if we used GraalVM Insight instead of home made TruffleInstrument
because you forced me to write Insight so it partially evaluates well
while our home made instrument runs behind @TruffleBoundary

I was mostly talking about memory footprint and interpretation overhead. It is still several indirections to get to your instrumentation code (even more with insight). A language specific implementation would be better in terms of memory footprint and interpreter performance.

For peak performance, instrumentation has no overhead on its own. Insight is worse than pure instrumentation for peak performance in the sense that it is always at least one guest level call which is comparable to a TruffleBoundary call (one that sets alllowInlining=true). With pure Truffle instrumentation you can implement this also without any call boundary, so you can theoretically achieve better performance than with insight (but its arguably less flexible as it needs to be baked into the native-image).

If I ever want to use Insight, then I will really need it to support more than expressions, roots and statements
Is that enough to justify Insight being extended with support for reads and writes tags?

It seams READ and WRITE instrumentation is covering all reads and writes in Enso, so this feature makes sense there. We also support it in Truffle instrumentation as a standard tag, so it also makes sense to support it in Insight. I mostly wanted to understand what your use-case and recommend alternatives, which I did now.

The change looks fine to me. Will integrate this.

[chumer]

@JaroslavTulach gate is still failing. Can you still adress this?
https://github.com/oracle/graal/actions/runs/20695924488/job/59411094992?pr=12760

[JaroslavTulach]

@JaroslavTulach gate is still failing. Can you still adress this? https://github.com/oracle/graal/actions/runs/20695924488/job/59411094992?pr=12760

• ecj not being compatible with javac when it comes to understanding Javadoc references:

----------
1. ERROR in /home/runner/work/graal/graal/tools/src/org.graalvm.tools.insight.test/src/org/graalvm/tools/insight/test/InsightAPI.java (at line 260)
	* {@link StandardTags.ReadVariableTag#NAME} is available.</li>
	         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Javadoc: Invalid member type qualification
----------
2. ERROR in /home/runner/work/graal/graal/tools/src/org.graalvm.tools.insight.test/src/org/graalvm/tools/insight/test/InsightAPI.java (at line 262)
	* {@link StandardTags.WriteVariableTag#NAME} is available</li>
	         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Javadoc: Invalid member type qualification
----------

• fixed in a344588

[JaroslavTulach]

The change looks fine to me. Will integrate this.

• CI seems to be green
• Is everything OK or do I need to do something on my side?
• When integrated: Do you have any (preliminary) plan when new JARs will be released to Maven Central?

[chumer]

Thanks for your contribution! I am currently running the internal CI.
The only fix I did was to move the changelog entry to the tools changelog.

There is no action required on your end. I will take it from here.

When integrated: Do you have any (preliminary) plan when new JARs will be released to Maven Central?

I think they should go out as part of EA soon. We do not have a release date for 25.1 yet.