Another question: does MRI trace the exit from the trace function? Since I suggested you do this in Ruby, that might be hard to avoid if not. Didn't even think of it until now.

@headius To answer your question with a "it seems so":

--- ruby/jruby ‹feature/4800-tracepoint-trace* ?› » JRUBY_OPTS=--debug irb -r ./vm_trace.rb
Ignoring byebug-9.0.6 because its extensions are not built.  Try: gem pristine byebug --version 9.0.6
irb(main):001:0> TracePoint.trace(:call) { |tp| puts tp.inspect }
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
=> #<TracePoint:enabled>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
#<TracePoint:call>
irb(main):002:0>
#<TracePoint:call>
#<TracePoint:call>

The last lines show me pressing Ctrl-D to leave the irb.

@headius Should we jettison this idea of using Ruby for a TracePoint patched implementation?

So here's the thing. It appears that MRI does trace the return from TracePoint.trace but it does so as a :c_return rather than a :return.

[] ~/projects/jruby $ ruby -e 'def bar; end; TracePoint.trace(:return) {|x| puts x.method_id }; puts :foo; bar'
foo
bar

[] ~/projects/jruby $ ruby -e 'def bar; end; TracePoint.trace(:c_return) {|x| puts x.method_id }; puts :foo; bar'
trace
to_s
foowrite

write
puts
puts

In JRuby, it's reversed, since we would implement it in Ruby instead of "C".

I'm not sure how important this is in practice. If there's logic that's attempting to hook only C methods, it will not see the return from trace. If there's logic that's attempting to hook only Ruby methods, it will see an unexpected return from trace.

Big deal? No big deal?

@olleolleolle I think we should just go with it and see what happens. Worst case we do a minor bit of porting and put it in Java.

As for tests, there might be something in spec/ruby but more likely there's a test excluded under test/mri/ruby/test_tracepoint.rb. The excludes are in test/mri/excludes with file path matching test class.

It might also be worth digging up any issue where this was added (in MRI) or opening a new one and clarifying with them how "spec" the :c_return vs :return is for cases like this.

Meh, I'm just going to use the Ruby version you provided to implement a Java version. I'm glad you got a chance to see how this fits together in JRuby, but we've already spent too long debating whether this minor difference is worth using Ruby for :-)

I said this on irc last week but I think semantically this should return :return if it is implemented in Ruby. Think of Rubinius/RubyTruffle or even MRI of the future where they start writing stuff in Ruby implwise (for inlining/JIT stuff). All this stuff will just change what they are implemented in. Any tests which return this as an error seems like an impl-specific test to me.

@enebo Yeah I never intended to tweak it so the Ruby version would do :c_return instead of :return. It's a minor difference, but it's also a five-minute patch to just write this in Java and moot the point.