Feature requests - perpetual thread

[Chuck Remes]

Volume on this list is low enough that I'm going to use it as a backup brain for a few requests.

PROFILER

1. A good chunk of the C-api in Rubinius is implemented as a rb_funcall back into a pure Ruby path. None of these paths show up during profiling. It would be great if they did show up so that it is easier to identify "slow paths" in C extensions.

2. On hydra (no-GIL branch) it would be interesting if there were an additional cli flag (-Xprofiler.by_thread ?) that would separate the statistics by thread. This sounds difficult, but it would be a helpful tool for identifying "hot" threads in a multi-threaded app. Additionally, it could probably help identify hot methods / bottlenecks where multiple threads come together for synchronization.

That's all for the moment.

cr

[Chuck Remes]

3. Add in the heap_dump (evanphx/heap_dump) functionality directly into rbx console (or make it a plug-in or something). It would be great to be able to write a command similar to this:

console> heap.diff(Time.now, Time.now + 60)

or

console> now_anchor = Time.now
console> 5.times do
console> sleep 60
console> heap.diff(now_anchor, Time.now)
console> end

to do heap diffs right in the console.

4. Extend the debugger so we can set breakpoint on stdlib or rbx internal Ruby code that is *called by* a C extension.

5. Provide a Ruby method for temporarily disabling the JIT around certain sections of code.

e.g.

def foo
Rubinius.jit :disable
<my code>
Rubinius.jit :enable
<other code>
end

Not hugely useful for all occasions, but there are a few times when you suspect code is problematic due to the JIT and you just want to get it out of the way.

cr

[Rocky Bernstein]

On Sat, Feb 19, 2011 at 10:03 PM, Chuck Remes <cremes....@mac.com> wrote:

3. Add in the heap_dump (evanphx/heap_dump) functionality directly into rbx console (or make it a plug-in or something). It would be great to be able to write a command similar to this:

console> heap.diff(Time.now, Time.now + 60)

or

console> now_anchor = Time.now
console> 5.times do
console>    sleep 60
console>    heap.diff(now_anchor, Time.now)
console> end

to do heap diffs right in the console.

4. Extend the debugger so we can set breakpoint on stdlib or rbx internal Ruby code that is *called by* a C extension.

I wasn't aware this wasn't possible. Can you come up with the simplest test case to try?  

Thanks.

5. Provide a Ruby method for temporarily disabling the JIT around certain sections of code.

e.g.

 def foo
   Rubinius.jit :disable
   <my code>
   Rubinius.jit :enable
   <other code>
 end

Not hugely useful for all occasions, but there are a few times when you suspect code is problematic due to the JIT and you just want to get it out of the way.

cr

--
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubini...@googlegroups.com
unsubscribe: rubinius-dev...@googlegroups.com

[Chuck Remes]

On Feb 19, 2011, at 10:34 PM, Rocky Bernstein wrote:

On Sat, Feb 19, 2011 at 10:03 PM, Chuck Remes <cremes....@mac.com> wrote:

3. Add in the heap_dump (evanphx/heap_dump) functionality directly into rbx console (or make it a plug-in or something). It would be great to be able to write a command similar to this:

console> heap.diff(Time.now, Time.now + 60)

or

console> now_anchor = Time.now
console> 5.times do
console>    sleep 60
console>    heap.diff(now_anchor, Time.now)
console> end

to do heap diffs right in the console.

4. Extend the debugger so we can set breakpoint on stdlib or rbx internal Ruby code that is *called by* a C extension.

I wasn't aware this wasn't possible. Can you come up with the simplest test case to try?  

Upon re-reading, I see that #4 is unclear. I *did* write it at midnight with a few whiskies in my system, so that's my excuse.

Allow me to clarify.

4. Extend the debugger so that we can set conditional breakpoints on stdlib or internal Rubinius Ruby code. This would be useful for breaking on Array#insert when it is called from a C extension but *not break* there when called by other code. A small example may help illustrate.

debug> break Array#insert if call_stack.include?("some function from a C extension")

This example would *only* break on #insert when it's called from a C extension, but other calls from normal Ruby code would not trigger the break.

I hope that is clearer. If not, perhaps I can try again (or the idea is half-baked to begin with).

cr

[Rocky Bernstein]

Thank you for the clarification. 

God willing, I think this will be doable in the not-too-distant future in the trepanning debugger, rbx-trepanning. Already you can do things like this in the patched YARV debugger using the gdb-like "condition" command. (Also in the YARV version, one can add conditions onto the end of a stepping commands.)

Currently the breakpoint structure in the Rubinius debugger has a field for storing a condition. But I don' t have any code right now for setting it or testing it when a breakpoint is hit. The code to parse a breakpoint command is at the stage where it is in need of rewriting. Some other commands that refer to locations like the "list" command are also way too complex in how they parse.

So fairly soon in the debugger I will be adding a PEG parser to be able to first parse locations, such are used in specifying breakpoints. Later the PEG grammar will handle better even more complex command jargon that you seem to want:

   break <location> if/unless <condition> 

where 

  <location> could be 

       a method name and an optional  line number or bytecode offset or 

       a file name and a line number

   and <condition> is some sort Ruby expression. 

So in sum, there is no technical reason why this can't happen; and it has been in the road map. It's just SMOP -- small matter of programming.

The idea is not half-baked.  

[Chuck Remes]

6. The heap_dump tool is fantastic for discovering you have a memory leak. Sometimes the information it provides is sufficient to fix the problem. However, sometimes just knowing the number of objects in the heap is insufficient.

I would like a tool that creates an "object reference stack" from the leaf node (that leaked) all the way back to its original owner.

e.g.

ruby% ruby reference_stacks dump1 LeakedClass
file7.rb:187 - Array.element 7 # element 7 is an instance of LeakedClass
file7.rb:55 - Hash.key 'a_key' # hash value for this key is the Array from line 187
file4.rb:21 - Bar#initialize # ivar refers to the hash from file7 line 55

file7.rb:187 - Array.element 6
file7.rb:55 - Hash.key 'another_key'
file4.rb:21 - Bar#initialize

etc.

[Rocky Bernstein]

After the upcoming Rubinius 1.2.2 release, I'll release another version of the trepanning debugger. In that release, I added  the  gdb "condition" command mentioned before. Hopefully this be able to do or at least get close to what you requested.