Alexander Jordan

I had a quick look at this and think we would need block enter/exit callbacks for this. Looks to me though that currently the graaljs instrumentation, which NodeProf relies on,...

Instrumentation support for `return` has been merged upstream in https://github.com/graalvm/graaljs/commit/e4bd649456362e66243b048cdb07993222c85696

I would advise against this: executing a `return` statement does not imply that the function indeed exits (`functionExit` does). `_return` is more closely related to control-flow than function, so adding...

`mx jalangi` uses `node` as the entrypoint for execution (note there is a difference in GraalVM between running pure JS `mx js` and Node `mx node`), thus you need to...

Sorry for the late reply! We are currently scoping how to provide the basic `forinObject` and `forofObject` callbacks in NodeProf.

Regarding **for-of** loops, Graal.js does not expose the events we would need to provide a `getField` callback. I'm actually not certain that this could be provided given the implementation will...

I'd like to separate issues for for-in and for-of and merge #48 if it sufficient to support for-in. @Haiyang-Sun can you please update #48 based on my comments and rebase/squash...

I proposed changes to the callbacks in #51. The instrumentation logic itself is unchanged.

@Haiyang-Sun in general it would be nice to have an easy way (ideally directly exposed by Graal.js instrumentation) to communicate which object is being iterated over. But in the end...

This seems to be by-design at the moment. I'll check if we run into any issues in our extended tests when we always pass the receiver object. If not, it's...