-
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: 2fd33bf3ad5d
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: 6f24fedf3ce2
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
7
contributors
Commits on Aug 31, 2015
-
Configuration menu - View commit details
-
Copy full SHA for 7444a80 - Browse repository at this point
Copy the full SHA 7444a80View commit details -
Configuration menu - View commit details
-
Copy full SHA for 2560bb8 - Browse repository at this point
Copy the full SHA 2560bb8View commit details -
Configuration menu - View commit details
-
Copy full SHA for 7277010 - Browse repository at this point
Copy the full SHA 7277010View commit details -
This was a well-intentioned idea but not practical or useful. The idea was to have the compiler help check where in call paths a garbage-collection cycle could run. Unfortnately, adding this in as an after-thought resulted in all the places where GCTokens are created from thin air deep in some call path. It didn't change the fact that GC could happen pretty much anywhere. In a managed runtime, either GC can happen everywhere or it should only happen at a very small number of extremely well-defined points. The middle ground of "it can happen at all these places" is an invitation for a low budget horror movie, dismembered objects strewn throughout the code. Along with the rework of the stop-the-world mechanism, the removal of GCToken and restricting the invocation of a GC cycle to a single well-defined method call in a few well-defined locations, and finally, making all allocation paths GC-safe (ie GC will NOT run when allocating an object), Rubinius will have much better defined GC behavior. The GC safe allocation path is important for cases like the string_dup instruction, where a young GC cycle could run when allocating the dup and the original String (eg a literal String in a method) is in the young generation and moved. Since the original String is on the C stack and not in a GC root object, the dup fails when copying the contents of the original String. It's better to make allocation GC-safe than to accept the performance cost of the GC root in these sorts of cases. Also, that case is only one well-defined instance of the issue. There are more complicated ones.
Configuration menu - View commit details
-
Copy full SHA for bace448 - Browse repository at this point
Copy the full SHA bace448View commit details -
These changes introduce a couple things: 1. All allocation paths are GC-safe. What that means is that when requesting a new object be created, the request will be fulfilled *unless* the system (or process limits prevent it) *without* GC running. In other words, there are two possible results of allocating an object: 1) a new object, or 2) an exception because no more memory is available to the process. In either case, from the point the object is requested until that request returns (or the return is bypassed by the exception unwind), the GC will not run. There is a trade-off here between running the GC at the instant that some threshold is breached (eg the eden space is exhausted) and loosening some requirements that must be maintained for a generational, moving garbage collector (ie every object reference must be known to the GC at the time the GC runs). Since we run GC on method entry and loop back branches, there is no reasonable scenario in which deferring GC until allocation has completed will result in unwanted object graph thresholds being breached pathologically (eg an execution path where allocation can grow unbounded). 2. All objects are allocated from the various heaps *uninitialized* and a protocol is established to call an initialization routine on the objects. The initialization routine is `T::initialize(State* state, T* obj)`, where T is the type of object being allocated. The method is a static method of the class of the object. This breaks with the protocol that Ruby uses where `new` is a module method and `initialize` is an instance method. The primary reason for choosing a static (ie C++ class) is to avoid an instance method operating on an incompletely initialized object. One purpose of this initialization protocol is to eliminate or reduce the double initialization that we were doing (ie setting all fields to nil and then initializing them to other default values). The main initialization method shown above may be an empty body, in which case the compiler will elide it anyway and there's no overhead to the protocol. In that case, another initialization method should be called on the newly created object. Since the allocation method is templated and if the initialization method is visible (ie in the header file), the compiler should be able to elide remaining double initialization in most contexts.
Configuration menu - View commit details
-
Copy full SHA for ca3011d - Browse repository at this point
Copy the full SHA ca3011dView commit details -
Configuration menu - View commit details
-
Copy full SHA for 3fde9fb - Browse repository at this point
Copy the full SHA 3fde9fbView commit details -
Configuration menu - View commit details
-
Copy full SHA for 3c05ffa - Browse repository at this point
Copy the full SHA 3c05ffaView commit details -
Configuration menu - View commit details
-
Copy full SHA for 08372d6 - Browse repository at this point
Copy the full SHA 08372d6View commit details -
Configuration menu - View commit details
-
Copy full SHA for 1743a37 - Browse repository at this point
Copy the full SHA 1743a37View commit details -
Configuration menu - View commit details
-
Copy full SHA for 10323d5 - Browse repository at this point
Copy the full SHA 10323d5View commit details -
Delay tracking VM objects until Thread is running.
In the case of `Thread.new`, the OS thread will never run because a ThreadError exception is raised when no block is passed. If we track the VM object that would ultimately contain the reference to the OS thread, we either need a way to remove the VM object when eg `Thread.new` raises an exception or we will leak these objects. Instead of tracking and then untracking the VM object, we create the object untracked and track it if the OS thread starts executing.
Configuration menu - View commit details
-
Copy full SHA for 66fca42 - Browse repository at this point
Copy the full SHA 66fca42View commit details -
Configuration menu - View commit details
-
Copy full SHA for 2834234 - Browse repository at this point
Copy the full SHA 2834234View commit details -
Configuration menu - View commit details
-
Copy full SHA for 37da04e - Browse repository at this point
Copy the full SHA 37da04eView commit details -
Configuration menu - View commit details
-
Copy full SHA for efa33da - Browse repository at this point
Copy the full SHA efa33daView commit details -
Configuration menu - View commit details
-
Copy full SHA for dc4ad6e - Browse repository at this point
Copy the full SHA dc4ad6eView commit details -
Configuration menu - View commit details
-
Copy full SHA for 8d2a439 - Browse repository at this point
Copy the full SHA 8d2a439View commit details -
Configuration menu - View commit details
-
Copy full SHA for 87821c5 - Browse repository at this point
Copy the full SHA 87821c5View commit details
Commits on Sep 2, 2015
-
Configuration menu - View commit details
-
Copy full SHA for b5975f2 - Browse repository at this point
Copy the full SHA b5975f2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3291521 - Browse repository at this point
Copy the full SHA 3291521View commit details -
Configuration menu - View commit details
-
Copy full SHA for bb3864e - Browse repository at this point
Copy the full SHA bb3864eView commit details -
Configuration menu - View commit details
-
Copy full SHA for 6c2f41f - Browse repository at this point
Copy the full SHA 6c2f41fView commit details
Commits on Sep 5, 2015
-
Configuration menu - View commit details
-
Copy full SHA for f8271d2 - Browse repository at this point
Copy the full SHA f8271d2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 5a588d5 - Browse repository at this point
Copy the full SHA 5a588d5View commit details -
Configuration menu - View commit details
-
Copy full SHA for 10b38c2 - Browse repository at this point
Copy the full SHA 10b38c2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 6dc58e3 - Browse repository at this point
Copy the full SHA 6dc58e3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 951aeb0 - Browse repository at this point
Copy the full SHA 951aeb0View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0521c3b - Browse repository at this point
Copy the full SHA 0521c3bView commit details -
Configuration menu - View commit details
-
Copy full SHA for 1f4f82d - Browse repository at this point
Copy the full SHA 1f4f82dView commit details
Commits on Sep 12, 2015
-
Configuration menu - View commit details
-
Copy full SHA for 5daca40 - Browse repository at this point
Copy the full SHA 5daca40View commit details
Commits on Nov 30, 2015
-
Configuration menu - View commit details
-
Copy full SHA for ff93ae9 - Browse repository at this point
Copy the full SHA ff93ae9View commit details
Commits on Dec 30, 2015
-
Configuration menu - View commit details
-
Copy full SHA for 891bbce - Browse repository at this point
Copy the full SHA 891bbceView commit details -
Configuration menu - View commit details
-
Copy full SHA for 899dca7 - Browse repository at this point
Copy the full SHA 899dca7View commit details
Commits on Dec 31, 2015
-
Configuration menu - View commit details
-
Copy full SHA for d265ed9 - Browse repository at this point
Copy the full SHA d265ed9View commit details -
Configuration menu - View commit details
-
Copy full SHA for d43ae9c - Browse repository at this point
Copy the full SHA d43ae9cView commit details
Commits on Jan 17, 2016
-
Configuration menu - View commit details
-
Copy full SHA for aa242ae - Browse repository at this point
Copy the full SHA aa242aeView commit details -
Configuration menu - View commit details
-
Copy full SHA for a8fec90 - Browse repository at this point
Copy the full SHA a8fec90View commit details
Commits on Jan 18, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 5d651e9 - Browse repository at this point
Copy the full SHA 5d651e9View commit details -
Configuration menu - View commit details
-
Copy full SHA for 172e032 - Browse repository at this point
Copy the full SHA 172e032View commit details -
Configuration menu - View commit details
-
Copy full SHA for f03ab0a - Browse repository at this point
Copy the full SHA f03ab0aView commit details
Commits on Jan 19, 2016
-
Configuration menu - View commit details
-
Copy full SHA for ce0c08d - Browse repository at this point
Copy the full SHA ce0c08dView commit details -
Configuration menu - View commit details
-
Copy full SHA for 6224161 - Browse repository at this point
Copy the full SHA 6224161View commit details -
Configuration menu - View commit details
-
Copy full SHA for d332e3e - Browse repository at this point
Copy the full SHA d332e3eView commit details -
Configuration menu - View commit details
-
Copy full SHA for b603b61 - Browse repository at this point
Copy the full SHA b603b61View commit details
Commits on Jan 20, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 78235a0 - Browse repository at this point
Copy the full SHA 78235a0View commit details -
Configuration menu - View commit details
-
Copy full SHA for b5197aa - Browse repository at this point
Copy the full SHA b5197aaView commit details
Commits on Jan 23, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 20cd1d3 - Browse repository at this point
Copy the full SHA 20cd1d3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0d1859b - Browse repository at this point
Copy the full SHA 0d1859bView commit details
Commits on Jan 24, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 03f8943 - Browse repository at this point
Copy the full SHA 03f8943View commit details -
Thread semantics are ad hoc in Ruby so we make a best effort to mimic them where possible. The behavior of process exit when one or more threads are suspended in a sleep state is not well-defined. We assume that no sleeping thread should block the process from exiting. We introduce a specific "sleep phase" as one state a thread may be in. We then ignore sleeping threads when executing a process exit. Unfortunately, this is more complex than it appears on its face. While executing a process exit, we are essentially racing any sleeping threads that may wake up and attempt to access resources that are being destroyed (something like one of those scenes from Inception with the buildings crumbling around the participants). We cannot waking thread proceed once process exit has started, so we permanently lock a mutex that every waking thread must acquire before progressing. Ultimately, these lock resources will need to be in the program's data segment, so they are static memory, not dynamically allocated, as they are now.
Configuration menu - View commit details
-
Copy full SHA for 903aae1 - Browse repository at this point
Copy the full SHA 903aae1View commit details
Commits on Jan 25, 2016
-
Configuration menu - View commit details
-
Copy full SHA for 4918136 - Browse repository at this point
Copy the full SHA 4918136View commit details
There are no files selected for viewing