On 2011-03-03, at 4:24 PM, Marc Feeley wrote:
In a compacting GC, objects are reached by the GC in 2 ways:
to "mark" them: this is done by following a tagged reference
to "move" them (or "update" them): this is done by sweeping the objects, so a tagged reference is not available... it is the object's header which identifies which type of object it is and the length (which are necessary to know the object's layout).
So we need a header on all objects that may be moved. We could avoid headers on objects that are not moved. On the other hand, having a uniform layout simplifies other things.
I should add that the header can be eliminated if objects of a given type are allocated in an area dedicated to that type (the BIBOP GC technique for example). So if floats are allocated in a different region then no header is needed for them. This may sound appealing, but there are other issues:
1) Each region will have its own allocation pointer. When there is just one region, the unique allocation pointer can be stored at all times in a single machine register, so allocation is really cheap. If there are multiple allocation pointers then they need to be fetched from the context, and stored back in the context. An allocation will require more machine code, and it will be slower.
2) Having more than one region can introduce fragmentation because the regions don't fill up at the same rate. When a GC is triggered some of the regions will not be full. This problem can be reduced by reducing the size of regions, but then they overflow more often, and this has a run time cost.
If floats are your only concern there is a solution which avoids headers on floats and uses only one allocation pointer. The idea is to encode the header of objects using a bit pattern which would be a NaN which can't be generated by floating point operations. So that way it is possible to distinguish a memory allocated float from an object header when the GC sweeps through the objects. The problem with this is that fewer bits in object headers are available to encode the type and length information, so for objets (in particular those with variable length), an extra field may be needed.
Marc