-
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: 1dcc82aa338a
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: 2aa0283dfc65
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 9 commits
- 132 files changed
- 4 contributors
Commits on Mar 2, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 4d7e389 - Browse repository at this point
Copy the full SHA 4d7e389View commit details
Commits on Mar 6, 2016
-
Configuration menu - View commit details
-
Copy full SHA for a4befe5 - Browse repository at this point
Copy the full SHA a4befe5View commit details -
Configuration menu - View commit details
-
Copy full SHA for bcbf8b6 - Browse repository at this point
Copy the full SHA bcbf8b6View commit details -
Configuration menu - View commit details
-
Copy full SHA for 477db7c - Browse repository at this point
Copy the full SHA 477db7cView commit details
Commits on Mar 12, 2016
-
CallFrame _invariants_ must be preserved under the following states: 1. calling / returning from _managed methods_; 2. calling / returning from _native methods_; 3. calling / returning from _native functions_; 4. calling / returning from _JIT functions_; 5. running a Fiber; 6. unwinding the stack due to C++ exception handling; 7. unwinding the stack by longjmp(); 8. before any managed code runs in a Thread; and 9. after all managed code has run in a Thread. CallFrame _invariants_ are: Assume a vector of references to CallFrame instances exists (VM::call_frames_), where n=VM::call_frames_index_ is the total number of CallFrame instances and VM::call_frame_ refers to VM::call_frames_[n-1], and VM::call_frame->previous refers to VM::call_frames_[n-2], etc. 1. VM::call_frames_[0] is the oldest managed frame in a Thread; 2. For all i=0...VM::call_frames_index_, VM::call_frams_[i] has 0+ live references to objects. 3. VM::call_frames_[VM::call_frames_index_-1] is the newest managed frame; 4. For all i=0...VM::call_frames_index_, VM::call_frames_[i+1] _follows_ VM::call_frames_[i], also stated as lifetime(VM::call_frames_[i]) _bounds_ lifetime(VM::call_frames_[i+1]) where lifetime(cf) returns a tuple (start, end) of times during which cf has live references, and for cf[i] "start_i" < "start_i+1" and "end_i" > "end_i+1".
Configuration menu - View commit details
-
Copy full SHA for 418cd0f - Browse repository at this point
Copy the full SHA 418cd0fView commit details -
Configuration menu - View commit details
-
Copy full SHA for b23f597 - Browse repository at this point
Copy the full SHA b23f597View commit details -
Avoid operating on (really) dead Threads.
The issue here is that Thread instances may be retained by other objects (eg Enumerator) and when the Thread instance itself is finalized, the order of finalization is non-deterministic (ie there is no Ruby API to impose an ordering on finalization), so a Thread instance may have had its memory for VM* cleaned up, and the other object referring to it may call methods on it when that other object is being finalized. So, we avoid operating on *really* dead Threads, where a Thread's lifetime looks something like this: 1. Memory for the Thread allocated, but the Thread is not running as a separate thread of execution. 2. The Thread is running. 3. The Thread's separate thread of execution has exited, so it is put in a "zombie" state, but all the memory for the Thread (except it's execution stack) is retained. 4. The Thread itself is still allocated (ie because the Thread is in a finalization list so its managed memory hasn't been recycled, or it's just been finalized) but the Thread isn't reachable by any live objects. 5. The Thread has been finalized, so it's VM* memory is deallocated, but the managed memory for the Thread itself hasn't been reclaimed. 6. The Thread's managed memory is no longer allocated and any reference to the Thread would be an "access after free" memory violation (but not necessarily one that would trigger a memory fault in the CPU because the region of memory it inhabited may still be allocated to the running program).
Configuration menu - View commit details
-
Copy full SHA for 8633f3e - Browse repository at this point
Copy the full SHA 8633f3eView commit details -
Fixed assumption of Symbol table size.
There is no guarantee that executing some Ruby code will only create one new Symbol instance. Since we lazily load code with the CodeDB, we could be executing code at any time in any thread, for instance.
Configuration menu - View commit details
-
Copy full SHA for f7370c3 - Browse repository at this point
Copy the full SHA f7370c3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 2aa0283 - Browse repository at this point
Copy the full SHA 2aa0283View commit details
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 1dcc82aa338a...2aa0283dfc65