-
Notifications
You must be signed in to change notification settings - Fork 605
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
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
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 755dc4bfccab
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: rubinius/rubinius
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 288636defc93
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 2 commits
- 24 files changed
- 1 contributor
Commits on Mar 31, 2016
-
Configuration menu - View commit details
-
Copy full SHA for e9943f7 - Browse repository at this point
Copy the full SHA e9943f7View commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 288636d - Browse repository at this point
Copy the full SHA 288636dView commit details
There are no files selected for viewing