[sgen] Remove a pointless memory barrier from the middle of the managed allocator.
authorAlex Rønne Petersen <alexrp@xamarin.com>
Thu, 26 May 2016 08:49:46 +0000 (10:49 +0200)
committerAlex Rønne Petersen <alexrp@xamarin.com>
Tue, 31 May 2016 21:40:29 +0000 (23:40 +0200)
This appears to serve no purpose as tlab_next is a thread-local variable. It's
only ever accessed by other threads in order to write to it, not read it. We
also don't do this memory barrier in the native allocation functions.

mono/metadata/sgen-mono.c
mono/sgen/sgen-alloc.c

index aaece7e29ca2b7d04c20ba7ead5b8fbb4a7e78a3..97aa337954fdc9c0aacd38d1effc9b45a9077a63 100644 (file)
@@ -1320,11 +1320,6 @@ create_allocator (int atype, gboolean slowpath)
        mono_mb_emit_ldloc (mb, new_next_var);
        mono_mb_emit_byte (mb, CEE_STIND_I);
 
-       /*The tlab store must be visible before the the vtable store. This could be replaced with a DDS but doing it with IL would be tricky. */
-       mono_mb_emit_byte (mb, MONO_CUSTOM_PREFIX);
-       mono_mb_emit_byte (mb, CEE_MONO_MEMORY_BARRIER);
-       mono_mb_emit_i4 (mb, MONO_MEMORY_BARRIER_REL);
-
        /* *p = vtable; */
        mono_mb_emit_ldloc (mb, p_var);
        mono_mb_emit_ldarg (mb, 0);
index 2bc3214f143745d39b577525eea5a6bbc257bd66..221b7ba7ea7145a4d5be21521cd46b8a4f68a289 100644 (file)
@@ -197,11 +197,6 @@ sgen_alloc_obj_nolock (GCVTable vtable, size_t size)
                if (G_LIKELY (new_next < TLAB_TEMP_END)) {
                        /* Fast path */
 
-                       /* 
-                        * FIXME: We might need a memory barrier here so the change to tlab_next is 
-                        * visible before the vtable store.
-                        */
-
                        CANARIFY_ALLOC(p,real_size);
                        SGEN_LOG (6, "Allocated object %p, vtable: %p (%s), size: %zd", p, vtable, sgen_client_vtable_get_name (vtable), size);
                        binary_protocol_alloc (p , vtable, size, sgen_client_get_provenance ());