hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering

[Charles Oliver Nutter]

On Thu, Jul 12, 2012 at 2:11 AM, John Rose <john.r.rose at oracle.com> wrote:
> One problem with mixed mode systems is that a method like
> "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a
> method name based on some value inside the frame itself.  Simply filtering
> or renaming JVM methods does not cover this case at all.

This is indeed the problem we face in JRuby. The Hidden annotation
might help us hide JRuby internals used for call-to-call plumbing, but
there's no static way to solve the problem of generating a trace for
interpreter frames.

Here's part of a Java trace from JRuby, with both compiled and
interpreted bits in it:

Trace snippit:

	at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:135)
	at org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:63)
	at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
	at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:75)
	at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:139)
	at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:175)
	at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566)
	at org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149)
	at blah.method__0$RUBY$foo(blah.rb:4)
	at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566)
	at org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149)
	at blah.__file__(blah.rb:13)
	at blah.load(blah.rb)

To generate a Ruby backtrace from this, we use the Java backtrace as a
"master" and mine out the interesting pieces. Specifically:

1. Elements with RUBY and __file__ in them are included because they
represent compiled Ruby code.
2. Any Java-based Ruby method in the trace is included, using a list
we maintain in JRuby as those methods are bound.
3. Interpreter entry points are indicated by INTERPRET_METHOD,
INTERPRET_EVAL, and so on. For each such element, we insert backtrace
data from our interpreter's backtrace stack (on heap)

This works well for Ruby code but does often omit frames users *want*
to see, like reflection-called Java methods.

Hiding would work for removing elements, but we'd have to tag a large
amount of JRuby code (like the entire interpreter) to remove
everything. Having an annotation to indicate the actual method name
would be useful for (2) above, but it would not do anything to help us
dynamically determine the frame for an interpreted section.

While I'd love to see better programmatic access to backtrace
generation, I can't really envision what it would look like.

On the plus side...the requirement that we always "assemble" our
backtraces from bits and bobs means we can do fun things like
alternative formatting and adding color :)

http://min.us/mbIkONLut

I dare say JRuby has the nicest stack traces of any language on the JVM.

- Charlie