Add very basic stat and debug options for method cache resets
Remove unused dlmalloc
Use strncpy over strcpy
Remove unused strlcat and strlcpy
Remove unnecessary use of invoke_primitive
Don't mark functions that allocate and could result in GC as read only

These can have side effects if they cause an actual GC because of memory
pressure. In that case it can also for example modify stack addresses
because objects are forwarded. LLVM shouldn't remove those cases.

The proper way to handle this would be to first do escape analysis and
if it doesn't escape, we could switch to stack allocation. That stack
allocation can then properly be seen as having no side effects.
Make debugging easier for Baker GC space

This makes two changes to make some debugging easier. First it marks a
certain as off limits so Valgrind can find errors if objects are used
that still refer to this old space.

The other is that we can easily set a flag to fill the unused space with
all 1's so any usage will very likely result in a segfault and makes
problems appear sooner rather than later.
Make sure to mark the areas as accessible before doing GC
Ensure we delete the condition when the lookup fails
Explicit return 0 compiler snack
Using the same source and target in snprintf is undefined behavior

According to the man page: "For those routines that write to a
user-provided character string, that string and the format strings
should not overlap, as the behavior is undefined".
Always push finalization information on the front

There might be multiple objects that need finalization that depend on
each other. The only really sensible case is an object that is created
later depends on an object created earlier. If both objects needs
finalization, the latest created object should be finalized first.

Changing this ordering here makes sure newest objects are finalized
first, so we work with a LIFO here instead of FIFO.
Reset method cache after defining a method through the C-API

This was problematic with the FFI extension. Problem was that because of
not resetting the method cache, if a function was redefined, Rubinius
would keep using the old cached definition. When that old definition was
cleaned up, since nothing in Ruby land referred to it anymore, it could
crash because of memory already been freed and reused.
Run all finalizers through the scheduling

This is another case where dependencies between finalizers can be
tricky. Data_Wrap_Struct uses a C finalizer for the free function if
that is requested. That means that this data gets cleaned up before any
other finalizers could run that depend on this data.

By treating all finalizers equally here, we can make sure that the
ordering of defining finalizers is also the reverse of when they are
executed.
Objects with a Ruby finalizer might also have a handle

Also unremembers these objects when they are remembered.
Zlib can be compiled with RSTRING_NOT_MODIFIED

Even though the zlib extension uses RSTRING_PTR and also modifies these
buffers, these cases aren't problematic. The ByteArray backing the
string is pinned so it won't move and there don't seem to be
dependencies on string sizes that could be handled wrong here.
Modify library/socket/socket/gethostbyname specs.

For specs "Socket#gethostbyname returns broadcast address info for
'<broadcast>'" and "Socket#gethostbyname returns broadcast address
info for '<any>'", only the first item (address) of returned array
is tested.

Later, some specs shall be added to verify that latest item of returned array contains
address as a packed string.
Modify Socket::Foreign.getaddrinfo to handle special host strings.

Modify Socket::Foreign.getaddrinfo to handle special host strings
'<any>' and '<broadcast>'.

Modification made for 1.8, 1.9 and 2.0 versions.
Prevent Data from being freed twice and marking when freed

There are situations where something happens to hold onto finalized
data, for example in the finalizer itself. Whatever does this or however
this happens, we should prevent double marking and free'ing here as a
safety net.

These objects usually get cleanup up then in the next cycle, it could
for example be that finalization was in progress at that time for those
objects when doing the GC.
Run both finalizers if present

We should run both finalizers if they are set. For example Data objects
with a Ruby finalizer, will have both set. We also need to run both, so
we properly clean up the object. Because of this we should first run the
Ruby finalizer, since the C finalizer might clean up memory etc.