[Mono-dev] [PATCH] Two patches to make SGen work on Darwin/x86

Paolo Molaro 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);
> +		mono_gc_register_root_wbarrier ((char*)hash, sizeof (MonoGHashTable), hash_descr);
> +#endif

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 mailing list