[Mono-dev] [PATCH] Two patches to make SGen work on Darwin/x86
lupus at ximian.com
Wed Mar 24 06:37:24 EDT 2010
On 03/24/10 Mark Probst wrote:
> The first patch make mono-ehash SGen-aware, the second implements
> CEE_MONO_TLS on Darwin/x86.
> --- a/mono/utils/mono-ehash.c
> +++ b/mono/utils/mono-ehash.c
> +#ifdef HAVE_SGEN_GC
> + if (type < 0 || type > MONO_HASH_KEY_VALUE_GC)
> + g_error ("wrong type for gc hashtable");
> + /*
> + * We use a user defined marking function to avoid having to register a GC root for
> + * each hash node.
> + */
> + if (!hash_descr)
> + hash_descr = mono_gc_make_root_descr_user (mono_g_hash_mark);
> + if (type != MONO_HASH_CONSERVATIVE_GC)
> + mono_gc_register_root_wbarrier ((char*)hash, sizeof (MonoGHashTable), hash_descr);
Uhm, when Zoltan changed the code in mono-hash.c to use this
mono_g_hash_mark root descriptor I had the gut feeling it wasn't
correct. Seeing the change again helped me focus on the bug this
Look at do_rehash in mono-ehash.c (mono-hash.c has a similar issue)
and imagine what happens when a GC occours just after these two lines:
table = hash->table;
hash->table = mg_new0 (Slot *, hash->table_size);
All the entries are reachable from table, but the GC can only see
from hash->table, which contains no hash table entries. This means the
objects me be deallocated or moved but their pointer in the hash won't
be updated, leading to crashes.
One solution is to introduce a function similar to
GC_call_with_alloc_lock() in the Boehm GC, so that the unsafe table
manipulation can be done without risk of interruption from the GC.
Another one is to expose the critical region enter/exit code from
sgen-gc.c. In both cases we must take care that no GC allocation can be
done inside the protected regions (the GC lock is not recursive and it
must stay that way).
The TLS change looks fine to me.
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list