JRuby support
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reading the debug.gem C extension and JRuby's startup instruction set, then review the ruby-debug conflict example in cli/ruby-debug/commands/irb.rb. Determine how JRuby would expose runtime frames, instruction sequences, and instruction-level breakpoints without debug hooks. Done means debug.gem works in JRuby startup mode with the stated debugging capabilities.
Written by the indexing model from the issue text.
Description
This issue describes a project to support JRuby in the debug library.
Background
JRuby has supported the same debugger as CRuby in the past via the ruby-debug gem (and to a lesser extent the old debug.rb). Back then, we worked with CRuby developers and IDE developers (such as those who worked on RubyMine from JetBrains) to have multiple backend libraries for ruby-debug that supported JRuby and CRuby.
In the intervening years, ruby-debug has bitrotted without any major updates in the past decade, and the new version of debug.rb has been greatly improved by @ko1 and others. This new debug.gem is now the standard for debugging Ruby code on CRuby.
ruby-debug today
The problem with ruby-debug today (other than it being very old and unmaintained) is that it depends on an older IRB that does not define any debug commands. As a result, when loading ruby-debug into a newer version of IRB (with debug.gem support), the commands that ruby-debug defines conflict, leading to errors and failing to boot.
$ rdebug
TypeError: superclass mismatch for class Continue
<module:ExtendCommand> at /Users/headius/work/jruby/lib/ruby/gems/shared/gems/ruby-debug-0.11.0/cli/ruby-debug/commands/irb.rb:32
<module:IRB> at /Users/headius/work/jruby/lib/ruby/gems/shared/gems/ruby-debug-0.11.0/cli/ruby-debug/commands/irb.rb:6
<main> at /Users/headius/work/jruby/lib/ruby/gems/shared/gems/ruby-debug-0.11.0/cli/ruby-debug/commands/irb.rb:5
The Continue class conflicts with a class of the same name added to IRB, and it's likely other classes would also conflict.
https://github.com/ruby-debug/ruby-debug/blob/ver_0_11_0/cli/ruby-debug/commands/irb.rb#L30-L33
It's likely that we can adapt ruby-debug for the IRB changes in the short term, but maintaining a completely separate debugging tool only for JRuby would not be efficient. So we desire to support debug.gem in JRuby.
Supporting JRuby
I have spent a little bit of time trying to understand the codebase and I think it is feasible (if difficult) for us to make debug.gem work with JRuby. Several things in JRuby are different, however, and would require some adaptation:
- There's a C extension mostly to access runtime call structures (frames etc) and instruction sequences (iseq).
We might need an extension in JRuby, or we could possibly just access these structures from Ruby code using our Java integration (but that Ruby code would have to be exempt from debug hooks, somehow).
- Breakpoints are installed at an instruction sequence level.
We would need to be able to support this in our instruction set.
- JRuby's instruction sequences are very different from CRuby's (some of the time).
JRuby has three different instruction sets: our "startup" set, which is a simple instruction set designed to parse, compile, and start executing quickly; our "full" instruction set, produced after optimization passes and providing a full control flow and data flow graph structure; and JVM bytecode, which we lazily compile to once code is hot.
The "startup" instruction set is the obvious target for debug.gem support. It is the simplest structure and would map most naturally to CRuby. It does not match CRuby exactly, however, so we would ned to adapt debug.gem to support both CRuby and JRuby instruction sets.
- JRuby would support
debug.gemonly in our "startup" mode with the simplest instructions and no optimization.
This should be sufficient for most debugging use cases, but it would obviously be slower than running one of our our optimized modes.
Alternatives
- We could just update and maintain ruby-debug. However, it's a large codebase and we are very limited on developer resources.
- We could provide better support for JVM debugging. JRuby can be set to always compile Ruby code directly into JVM bytecode, and in this mode most Ruby methods would work properly with JVM debugging APIs. However, the structure of classes and objects in JRuby is quite different from standard JVM objects, so setting watches and exploring the heap would be rather foreign.
- We could again try to work with IDE vendors like JetBrains to support debugging. Unfortunately JetBrains has reduced efforts to support Ruby in recent years and the last time I reached out to them they were not interested in major RubyMine work.
- Dominant language
- Ruby
- Stars
- 1.3k
- Forks
- 146
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ruby/debug
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Support exceptionOptions in setExceptionBreakpoints to catch arbitrary exception classes via DAP Open
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Similar issues
-
バグ
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
voxpupuli/puppet-epel#186 · 1 comment ·
-
external_created_at is no longer used for the message timestamp since the new message UI (v4.4.0) OpenBug Frontend
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
TheOdinProject/curriculum#31402 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100