The maintained constants table is dealing with symbols but these methods can take strings as arguments ; it's pretty common to pass `class.name` as an argument.
Ruby 2.3 ships with a new `Numeric#negative?` method. Rubinius implements this method since b92c84f, for internal usage though ; it delegates to the signbit C++ function. However, `signbit`'s behavior can't match MRI `Float#negative?`'s one since the former operates on the sign while the latter operates on the value (see http://git.io/vm1fg).
Ruby generally makes no guarantees about thread safety, however, many accidental "guarantees" are assumed by Ruby programmers because of MRI's global interpreter lock. Rubinius makes internal operaions thread safe but generally does not make any thread safety guarantees for common Ruby objects like Array or Hash instances. It's perfectly possible to "corrupt" an Array by concurrently modifying it without synchronization. ThreadGroup presents an interesting case, however, because it is arguably a system structure. The API of ThreadGroup is minimal, consisting of these methods: add, enclose, enclosed?, list. Of these, only add presents a thread safety issue from the perspective of a potentially "corrupted" structure (ie the list of Threads in the group). It's possible for one Thread to enclose the group and another to get 'false' when calling #enclosed? "after" the other Thread called #enclose. That's not a case we are concerned with. The case of calling #add (which will implicitly also remove the Thread from another group if it is a member) should probably be thread safe. For this reason, we add synchronization around adding (and removing) a Thread from a ThreadGroup.
This is the first step of a much refactor to introduce a proper System object instead of hanging all the process boot and halt logic off the Environment object. A lot of boot and halt code can then be cleaned up (eg creating and initializing the object space, loading the kernel code, etc). The main process thread (the one the OS creates when the process is first created) now boots the system and spawns a thread to start running Ruby code. The main thread goes on to process signals and halting the process. This is the only thread that processes halt code. When the process forks, a new thread is created to process signals and halting. In the future, fork() and exec() will be disallowed on all internal threads and only allowed on threads running Ruby code.