Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Branch: dibuilder-memo…
Commits on Mar 29, 2013
  1. Plug memory leaks of DIBuilder

    Checked with LLVM 3.0, 3.1, 3.2, 3.3
Commits on Mar 28, 2013
  1. @dbussink

    Use set inflated header helper where appropriate

    dbussink authored
    We can use the set_inflated_header method in these two places instead of
    writing the same code manually.
  2. @dbussink

    Use inflation functions consistently

    dbussink authored
    We don't pass down the objectmemory to other similar methods, so don't
    do it for this one either. Also move find_index to the header so it can
    be inlined in places where it's used.
  3. @dbussink

    Make error message more explicit about what the problem is

    dbussink authored
    Apparently it still wasn't clear what the issue was, given we still got
    issues opened on this problem. Make it even more explicit so people
    hopefully read it all now and know how to solve it.
  4. @dbussink

    Switch to LLVM 3.2 as the default for prebuilts

    dbussink authored
    There are now prebuilt LLVM images for OS X 10.6, 10.7, 10.8 and Linux
    versions based on GCC 4.1, 4.2, 4.3, 4.4, 4.5, 4.6 and 4.7, both for
    i686 and x86_64 architectures. This should cover most of the systems
    that people use.
  5. @dbussink

    Fix building for LLVM from source

    dbussink authored
    Also removes old unused debugging tasks and uses system() like Daedalus
Commits on Mar 27, 2013
  1. @dbussink

    Increase default IOBuffer size to 32k

    dbussink authored
    Results in another significant performance increase for, since
    it has to flush the buffer fewer times.
  2. @dbussink

    Introduce ByteArray::create_dirty and use where safe

    dbussink authored
    This allocates a ByteArray without zero'ing all the memory. This is for
    example useful when used in String::create, where the memory will be
    overwritten anyway. Other cases are where ByteArray used as backing
    store for Bignum and Regexp.
  3. @dbussink

    Use a larger stack buffer when filling IOBuffer

    dbussink authored
    Increases performance of reading IO, for example for
  4. @dbussink

    Clear all allocated bytes in ByteArray::create

    dbussink authored
    This makes sure there are no non zero bytes in the resulting memory,
    which could result in information leakage for example that people would
    not expect.
  5. @dbussink

    Ensure that the saved TZ is actually 0 terminated

    dbussink authored
    Valgrind caught this by marking it as an uninitialized jump, because
    strcmp was used later on.
  6. @dbussink

    Remove unneeded OnStack in VariableScope

    dbussink authored
    The original problem was not due to the variable not being marked
    OnStack, but because of another initialization ordering issue. This was
    added during debugging, but should have been removed before committing
    the code.
  7. @dbussink
  8. @dbussink
  9. @dbussink

    Merge pull request #2232 from YorickPeterse/master

    dbussink authored
    Fix for retrieving UnboundMethod parameters
  10. @dbussink

    Use a general reference check, not only cTrue

    dbussink authored
    There shouldn't be any other immediates set than cTrue, but using a
    reference check is a better match for the needed behavior and would
    prevent a crash if anyone manages to set another immediate.
  11. Merge pull request #2239 from ryoqun/finalizer-gc-crash

    Fix Crash with ObjectSpace.define_finalizer(obj)
Commits on Mar 26, 2013
  1. @carlosgaldino

    Merge pull request #2238 from stouset/getbyte-gets-bytes-not-chars

    carlosgaldino authored
    StringIO#getbyte should work in terms of bytes rather than characters
  2. Fix Crash with ObjectSpace.define_finalizer(obj)

    This code produces a crash:
        class Foo
          def __finalize__
        foo =
    When run:
        CRASH: A fatal error has occurred.
    ObjectSpace.define_finalizer stores cTrue as a finalizer placeholder in this
    case. And when GC runs, it doesn't consider there may be immediates and
    dereferences that cTrue. Thereby, a crash is waiting for you. :p
  3. @stouset
  4. @stouset

    Add failing specs for issue #2215

    stouset authored
  5. @dbussink
  6. @dbussink

    Don't setup GC state around waiting for JIT requests in sync mode

    dbussink authored
    The JIT thread itself managed the GC state of LLVMState, so we shouldn't
    interfere with that logic from the compile_soon logic that actually gets
    executed by another thread.
    Fixes #2226
  7. @dbussink

    Make StringIO operations byte based

    dbussink authored
    StringIO works like an IO object and basically operates on strings as
    them being byte arrays without encodings. This fixes a bunch of test
    failures on Nokogiri as well, which uses a StringIO internally and got
    results back with the wrong encoding.
    Also fixes #2163 because the wrong encoding came out, because the
    encoding aware methods used in StringIO before would change the encoding
    if a ASCII-8BIT string was written to the StringIO. With this change,
    they retain the original encoding, so things come out in the right
    encoding from Nokogiri.
  8. @dbussink
  9. @dbussink
  10. @dbussink

    Prevent having to search twice when adding handle to slow handle set

    dbussink authored
    This uses the return value of the insert to determine if the value was
    already in the set or not, so we only reference it if it was newly
  11. @dbussink

    Use std::set since it never invalidates on insert()

    dbussink authored
    When flushing handles, it can happen that new handles are added to the
    set. This mainly happens for cases where we flush an RArray handle,
    because that also gets handles for all elements in the array.
    std::tr1::unordered_set doesn't give the insert guarantees we need,
    Iterator validity
    On most cases, all iterators in the container remain valid after the
    insertion. The only exception being when the growth of the container
    forces a rehash. In this case, all iterators in the container are
    So if a rehash is forced, all iterators are invalid. This means we have
    undefined behavior that can result for example in crashes (which was
    happening in the Nokogiri test suite for example).
    std::set explicitly states it doesn't affect iterator validity, so it
    doesn't suffer from this problem. The downside is less performant
    insert() but there isn't really another option without redoing this
  12. @dbussink

    Merge pull request #2235 from ryoqun/valgrind-error-hits

    dbussink authored
    Set hits to 0 for inline block's JITMethodInfo
  13. Set hits to 0 for inline block's JITMethodInfo

    This fixes the following valgrind error:
        ==13303== Thread 4:
        ==13303== Conditional jump or move depends on uninitialised value(s)
        ==13303==    at 0x7826ED: rubinius::Inliner::inline_for_class(rubinius::Class*, int) (inline.cpp:159)
        ==13303==    by 0x782312: rubinius::Inliner::consider_mono() (inline.cpp:35)
        ==13303==    by 0x7A9EFE: rubinius::JITVisit::visit_send_stack(unsigned long, unsigned long) (jit_visit.hpp:1481)
        ==13303==    by 0x7A1CD6: rubinius::VisitInstructions<rubinius::JITVisit>::dispatch(int) (jit_visit.hpp:1565)
        ==13303==    by 0x7A1426: rubinius::jit::Walker::call(rubinius::OpcodeIterator&) (jit_builder.cpp:554)
        ==13303==    by 0x7A11B4: void rubinius::jit::ControlFlowWalker::run<rubinius::jit::Walker>(rubinius::jit::Walker&) (control_flow.hpp:49)
        ==13303==    by 0x79FB30: rubinius::jit::Builder::generate_body() (jit_builder.cpp:591)
        ==13303==    by 0x788576: rubinius::Inliner::emit_inline_block(rubinius::JITInlineBlock*, llvm::Value*) (inline.cpp:648)
        ==13303==    by 0x78809A: rubinius::Inliner::inline_block(rubinius::JITInlineBlock*, llvm::Value*) (inline.cpp:284)
        ==13303==    by 0x7AD231: rubinius::JITVisit::visit_yield_stack(unsigned long) (jit_visit.hpp:2709)
        ==13303==    by 0x7A1E55: rubinius::VisitInstructions<rubinius::JITVisit>::dispatch(int) (instruction_visitors.hpp:62)
        ==13303==    by 0x7A1426: rubinius::jit::Walker::call(rubinius::OpcodeIterator&) (jit_builder.cpp:554)
    This valgrind error is introduced by this commit:
        Don't inline calls for not often called methods
  14. @dbussink
  15. @dbussink
  16. @dbussink

    Use RBOOL and CBOOL where appropriate

    dbussink authored
    In a lot of places we used ? : or multiple return style to return Ruby
    boolean values. We have a helper for that, RBOOL so we might as well use
    it. Also switch to using CBOOL where it's appropriate for Ruby to C(++)
    boolean checks.
Something went wrong with that request. Please try again.