[Gc] Switching the atomic property of an object

Bruce Hoult bruce at hoult.org
Wed Jun 13 18:44:54 PDT 2012

On Thu, Jun 14, 2012 at 12:40 PM, Alex Rønne Petersen
<xtzgzorex at gmail.com> wrote:
> In my virtual machine where I'm using libgc, every object has a header
> that contains a potential pointer into GC-allocated memory. This
> currently forces me to never allocate memory as atomic, even if I know
> that the object body itself will contain no GC pointers. The potential
> pointer in object headers is simply a user data field of sorts. For
> the vast majority of objects, it will never be set. This is a bit of
> an annoying situation, since I have to be conservative just because of
> that one potential pointer.
> So my question is this: Is there any way to flag on/off whether an
> object is atomic?

No, it's not possible. Atomic and non-atomic objects are allocated in
mutually-exclusive memory pages. The fact that it is atomic or not is
indicated by which kind of page it is in.

If the vast majority do not have this pointer then consider one of the

1) don't put the pointer in the object, but in a hash table keyed by
the object address. You can use a finalizer to delete the user data
from the hash table when the object is collected. You could put a
boolean in the object to indicate whether there is user data, to avoid
needless hash table lookups.

2) as in 1) but have a pointer in the object which points to the user
data if the object is otherwise non-atomic, and to a special value if
the object is atomic indicating that the hash table should be
checked). Then you don't need a separate boolean.

3) as in 2), but have the pointer always point to the user data, and
ensure that your hash table is scanned by the GC. This will cause your
user data to be retained even though the object itself might not be

4) allocate two objects, a non-atomic one that contains only a pointer
to the user data and a pointer to the rest of the object, and the rest
of the object. This will waste one pointer per object, and a small
amount of time in extra allocations and dereferences.

More information about the Gc mailing list