Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DTrace/SystemTap object allocation hooks, method cache reset hooks and some housekeeping #3214

Closed
wants to merge 6 commits into from

Conversation

yorickpeterse
Copy link
Contributor

NOTE: This pull-request is still a work in progress, I'm creating it to get some early feedback.

This pull-request adds the following:

  1. A setup for tracing object allocations using DTrace/SystemTap (plus a few calls to these hooks)
  2. A change that replaces RBX_DTRACE_CONST char* with just RBX_DTRACE_CHAR
  3. Hooks for tracing method cache resets

The first item is the most interesting: it allows you to trace allocations using the "object__allocate" probe. For example (this is a SystemTap script):

global allocations

probe process("rbx").mark("object__allocate")
{
    klass = user_string($arg1)
    file  = user_string($arg2)

    allocations[klass, file] <<< 1
}

probe end
{
    printf("%-40s %-6s %s\n", "Class", "Amount", "File")

    foreach ( [klass, file] in allocations- )
    {
        printf("%-40s %-6d %s\n", klass, @count(allocations[klass, file]), file)
    }

    delete allocations
}

This would count the amount of object allocations per class and file and display the results upon exiting SystemTap. While still in an early stage this has already proven useful in finding allocation patterns for #3205 .

Right now there are hooks for the following classes:

  • Array (given Array::allocate is used)
  • Generic Ruby objects (those allocated by Class::allocate)
  • String (given String::allocate is used)

The tricky part here, and this is something I'll need some feedback on, is to where exactly add the hooks. Some C++ classes have an allocate methods while others use a create method, sometimes even both. Ideally all allocated objects that are exposed to Ruby should be traceable using these hooks. Because I'm not really sure where exactly to add the hooks I've so far only added them to the classes noted above.

The second thing changes is the introduction of RBX_DTRACE_CHAR. This is mostly a cleanup thing. I got tired of having to type RBX_DTRACE_CONST char* all the time, thus I introduced this little macro.

Last, I added a hook for tracing method cache resets. This is pretty self-explanatory, the probe is called method__cache__reset.

Yorick Peterse added 4 commits November 14, 2014 19:47
This currently only traces classes allocated in the Ruby side of things. String,
Array and other allocations are not yet tracked.
For whatever reason this will either 1) report file names as method names 2)
crash once in a while. Either way, it's a start.
This means that instead of doing const_cast<RBX_DTRACE_CONST char*> you can
write const_cast<RBX_DTRACE_CHAR>.
@yorickpeterse yorickpeterse self-assigned this Nov 14, 2014
@yorickpeterse yorickpeterse changed the title DTrace/SystemTap object allocation hooks plus some housekeeping DTrace/SystemTap object allocation hooks, method cache reset hooks and some housekeeping Nov 14, 2014
@yorickpeterse
Copy link
Contributor Author

Worth noting: in 1df5a70 I mentioned that the probe might sometimes crash Rubinius. I haven't really experienced it lately and I don't really remember if it was related in the first place (e.g. it could've been an unrelated crash).

@brixen
Copy link
Member

brixen commented Nov 26, 2014

In general, it's good to separate clean up like RBX_DTRACE_CONST char* (which should be RBX_DTRACE_CHAR_P) from substantive changes.

As for the additional hooks, I don't want to add these yet because allocation is going to change significantly and I'd rather not add an API that we're going to immediately change.

@yorickpeterse
Copy link
Contributor Author

What's the timeline for the allocation process changing? Is this something that will happen within the new few weeks, or are we walking about multiple months from now?

@brixen
Copy link
Member

brixen commented Nov 28, 2014

@yorickpeterse very soon, it's a critical building block for a bunch of 3.0 stuff.

@yorickpeterse
Copy link
Contributor Author

@brixen Fair enough. For the DTrace char macro, do you first want to further review it or can I just yank that into master right away?

yorickpeterse pushed a commit that referenced this pull request Dec 15, 2014
This has been extracted from #3214
base on feedback from @brixen.
@yorickpeterse
Copy link
Contributor Author

The const char * stuff has been extracted into commit 7da4c6d. I'll close this PR due to the upcoming changes regarding allocations, once those are in place can revise adding extra dtrace/systemtap hooks.

@yorickpeterse yorickpeterse deleted the dtrace-boxing branch December 15, 2014 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants