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

[Rémi Forax]

On 07/12/2012 07:14 PM, Charles Oliver Nutter wrote:
> 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.

I agree, but it will greatly simplify the problem because stacktrace will
be smaller so it will be faster to patched them.

>
> 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.

A special method handle acting as a decorator should be enough :)
Let say we have a static method backtraceDecorator in MethodHandles
that takes a target method handle and returns a new method handle.
The new method handle will have a supplementary parameter of type String
before all parameters, the content of this parameter will be used
instead of the method name of the target method in the stack trace.
So basically, the handle handle will change the method name of the 
method handle
taken as argument, so the target method handle must be either a constant 
method handle
or the result of a lookup.find* or lookup.unreflect*.

Now in the runtime instead of calling INTERPRET_METHOD directly, the 
runtime should
call the method handle created like this:
    MethodHandle interpreterEntryPoint = MethodHandles.backtraceDecorator(
       lookup.findVirtual(..., ''INTERPRET_METHOD"));
and this method handle should be called with the method name as first 
parameter.

>
> 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

cheers,
Rémi