On Wed, Jun 17, 2009 at 7:37 PM, James Abley <james.ab...@gmail.com> wrote:
> One thing that I've encountered recently is the inability to debug
> Ruby code (set breakpoints, etc) along with breakpoints in Java code -
> I can only debug one layer (tried with Eclipse and IDEA; can't do it
> in Netbeans either, but I don't know Netbeans very well).
Ok, so I've been AWOL this whole week and going on vacation next, but
I wanted to jump in here with a few thoughts.
1. Debugging across languages still totally depends on having real
bytecode *somewhere*. You could debug JRuby's interpreted mode, but it
would be just about the most painful thing ever. I'd love to see the
JVM enhanced to provide debugging hooks for alternative languages in
interpreted modes, but I know of no such work.
2. JRuby can run in a mode where it is 100% compiled (modulo some
problem areas like larger-than-64k bodies), and then Ruby code shows
up with .rb code and line numbers right in the stack trace. It's
actually pretty clean:
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:258)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:77)
at test.method__2$RUBY$baz(test.rb:10)
at testInvokermethod__2$RUBY$bazFixed0.call(test#baz)
at testInvokermethod__2$RUBY$bazFixed0.call(test#baz)
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:258)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:77)
at test.method__1$RUBY$bar(test.rb:6)
at testInvokermethod__1$RUBY$barFixed0.call(test#bar)
at testInvokermethod__1$RUBY$barFixed0.call(test#bar)
And with "inlineDyncalls", a somewhat tighter call protocol:
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:258)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:77)
at test.method__2$RUBY$baz(test.rb:10)
at testInvokermethod__2$RUBY$bazFixed0.call(test#baz)
at testInvokermethod__2$RUBY$bazFixed0.call(test#baz)
at test.method__1$RUBY$bar(test.rb:6)
at testInvokermethod__1$RUBY$barFixed0.call(test#bar)
at testInvokermethod__1$RUBY$barFixed0.call(test#bar)
3. The problem, in JRuby's case, is that even when running in
fully-compiled mode, none of the available Ruby tooling recognizes
Ruby code as Java-debuggable. All efforts to support Ruby debugging
have focused on what would work in both CRuby and JRuby, so it's all
Ruby's debug protocols. That all works great, but there's no
integration with Java debugging as a result. HOWEVER...I don't think
it would be hard to hook into any given debugger. Any new language
getting going on the JVM faces exactly the same problem, so I suspect
this will move toward a general solution soon.
I've done it myself with jdb, when I know what the class names I'll
generate will be:
http://gist.github.com/131637
4. Another smaller problem with JRuby is that because we've always
focused on having a mixed-mode execution, a lot of the filenames
embedded in the bytecode are either bogus or complete canonical paths,
neither of which helps a Java debugger out very much. But that's a
solvable problem, possibly by just embedding a better path to the
source or by embedding a couple different paths using JSR-45.
Ultimately, the only reason JRuby has complications here is because we
opted to support an interpreted mode forever, which on the JVM isn't
supported particularly well. But this is an area we recognize we need
improvement, and the next version or two of JRuby are going to have a
much tighter focus on integrating with the rest of the platform. This
means getting debugging working nicely (probably by contributing to
the IDEs a bit or working with them), getting profiling a bit cleaner
and more usable (it works now, but again the interpreted mode skews
the results a lot; knowing that CallNode.interpret is hit hard isn't
really helpful), and perhaps most importantly, pulling Ruby and Java
type systems closer together at the JVM level, to solve the "last
mile" of platform integration.
We welcome help on any and all of these, because they're problems any
language from off-platform will face...and making the JVM a better
home for unusual off-platform languages is perhaps the most important
task ahead of us.
- Charlie
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
