Monday, March 12, 2012

Support for user header data

It's very common for languages to need to attach some sort of information to objects in memory. At first glance, doing this with MCI seems easy: Just insert an extra hidden field on all types. Problem solved!

... Except, what about arrays and vectors?

It's perfectly normal to want to attach some language-specific type information to arrays and vectors in addition to plain objects. For instance, your language may want to keep information about the array's specific encoding, or perhaps some element type qualifiers need to be stored.

For this reason, we've added an extra field to the header of all RuntimeObject instances. It's a word-sized field which can hold any reference type (i.e. a plain reference, an array, or a vector). It can be accessed through the new field.user.addr, field.user.get, and field.user.set instructions.

This design does mean that there's an entire word of extra memory for all managed objects. This new field can be useful, but in cases where you don't need it, it just sits there eating memory for no good reason.

Unfortunately, there's no good way to get rid of the field when a program doesn't use it. It would introduce a lot of ABI compatibility issues to let programs disable it (and also complicate a lot of MCI code). We do recognize that on 32-bit machines, that extra word can actually make a difference, but the world is obviously moving towards 64-bit architectures these days, and so we've chosen to simply rely on the vastly increased address space in those.

Thursday, March 1, 2012

Introducing libgc-d

We've just published libgc-d on GitHub (and it is building on the CI server as well)!

This is a bare-bones binding to the libgc library (also known as the Boehm-Demers-Weiser GC). It is a conservative garbage collector targeting applications written in languages such as C, C++, D, etc. We're using libgc-d in MCI as we now support libgc as a garbage collector option on all non-Windows platforms.