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: 755dc4bfccab
Choose a base ref
...
head repository: rubinius/rubinius
compare: 288636defc93
Choose a head ref
  • 2 commits
  • 24 files changed
  • 1 contributor

Commits on Mar 31, 2016

  1. Some Arguments tweaks.

    @brixen
    brixen committed Mar 31, 2016
    Configuration menu
    Copy the full SHA
    e9943f7 View commit details
    Browse the repository at this point in the history

  2. Fixed issues with concurrent marking. 

    As noted in one of the comments in this commit, there is a serious issue with
partially initialized data when we have a concurrent marking thread running.
When a Tuple is created, but the fields are not initialized to nil, they may
contain random data.

When a value is stored into a managed object, we run a write barrier. This bit
of code serves two functions. First, it "remembers" the object being stored in
case the object it is being stored into is a mature object and the object
being stored is a young object. When the young collector runs, those
"remembered" objects are part of the roots for the young region being
collected. Second, if the object being stored into hasn't been traced yet, we
trace it, and we add the object being stored to the stack of objects to trace.

If the Tuple fields aren't initialized, we'll hit a garbage value when we try
to trace it. If we don't run the write barrier when we assign values, we have
the chance of losing one of those references. An alternative to "doubly
initializing" the Tuple instance is to run two loops. One that assigns values
and one that runs the write barrier on the entries. It should be apparent that
we haven't really saved anything by using this purported "optimization" of
creating the Tuple uninitialized (dirty).

This is a good lesson in optimizing. The best optimization is not running any
code at all, rather than making running code faster, if that is an option. It
usually will give greater return to rework code in a way that significant code
can be eliminated vs "optimized". In this case, we should get rid of Array and
Tuple in the middle of stuff like calling methods.
    @brixen
    brixen committed Mar 31, 2016
    Configuration menu
    Copy the full SHA
    288636d View commit details
    Browse the repository at this point in the history