Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: rubinius/rubinius
base: 045796e39b74
Choose a base ref
...
head repository: rubinius/rubinius
compare: aa83a0c7416d
Choose a head ref
  • 3 commits
  • 12 files changed
  • 1 contributor

Commits on Mar 28, 2016

  1. Reworked concurrent mark thread.

    The primary reason to use a concurrent marking strategy is to reduce the time
    during which the mutator threads are suspended while marking all reachable
    objects.
    
    However, not running the GC synchronously when a memory threshold is reached
    (eg when the Immix region has exhausted available chunks) means that heap
    growth or spill over to another region (eg the Large Object Space) is
    essential.
    
    The growth is undesirable (because right now there is no compaction and growth
    will continue unbounded) and the spill is especially undesirable because the
    LOS collector is much less efficient than the Immix collector.
    
    Since the marker thread is essentially racing the mutator threads, under high
    allocation rates, the marker would be perpetually behind and a lot of growth
    or spill would occur.
    
    Eventually, we'll implement compaction, which will mitigate heap growth. But
    that doesn't solve all the problems. To address these issues, we adhere to the
    following constraints:
    
    1. We don't defer collection. When the first memory threshold is reached, we
    perform synchronous GC and then create the concurrent marker thread.
    2. We respect memory thresholds. We revert to a synchronous collection cycle
    when the concurrent marker cannot keep up with the mutator. Basically, this
    means finishing the GC cycle whenever the threshold is hit.
    3. The concurrent marker restarts its work immediately after finishing a GC
    cycle instead of waiting for memory thresholds to be breached. The concurrent
    marker thread then sleeps for random intervals waiting for the mutators to
    produce more objects to scan.
    brixen committed Mar 28, 2016
    Copy the full SHA
    edd398c View commit details
    Browse the repository at this point in the history
  2. Copy the full SHA
    9b49b9b View commit details
    Browse the repository at this point in the history
  3. Copy the full SHA
    aa83a0c View commit details
    Browse the repository at this point in the history