[Mono-bugs] [Bug 65414][Nor] Changed - [PATCH] Thread Local Data Slots do not survive nested appdomain transitions
Wed, 8 Sep 2004 08:49:24 -0400 (EDT)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by firstname.lastname@example.org.
--- shadow/65414 2004-09-08 08:00:35.000000000 -0400
+++ shadow/65414.tmp.26312 2004-09-08 08:49:24.000000000 -0400
@@ -199,6 +199,38 @@
objects from a domain to the other (which creates the same sort of
issues of the current thread object being shared).
Having domain-indep code in the vtable would also mean that access to
thread-static vars would become slower (unless we do other hacks) than
the access to a field which would be set correctly once per appdomain
transition in mono_domain_set().
+------- Additional Comments From email@example.com 2004-09-08 08:49 -------
+If I do your suggestion, where exactly do I store the TLS hashtable
+when I switch appdomains? If I switch into the appdomain I was
+switching out of, I need to be able to quickly find this hashtable. I
+guess I could store a MonoGHashTable in the thread and index Thread
+ID -> tls store. Idealy, however, I would like to be able to switch
+between appdomains without transitioning into unmanaged code (if no
+marshaling of arguments is needed [eg, they are all primative]). This
+will make xsp requrests faster
+I think now I like the idea of allocating space in the same area we
+allocate [ThreadStatic] variables for the Get/SetData slots. It
+should be much faster than using a hashtable, and does not require
+any work on appdomain switches. If we assume that either
+[ThreadStatic] or Get/SetData is going to be used at least once in
+every thread, it actually turns out that we do not waste that much
+memory. Allocating a Hashtable (which will need to be done for
+Get/SetData) requires allocating an object with a few fields. It is
+probably somewhere on the order of 32 bytes. Also, it creates a Slot
+ of size 16. so that requires 16 * (sizeof (void*) * 2 + sizeof
+(int)) + sizeof (MonoArray) bytes. Allocating the [ThreadStatic] area
+is just going to require that we allocate the array of 1kb for the
+first section of data. In fact, maybe it would make sense to make the
+first section 128 bytes or something. This would be more than enough
+for one appdomain's data. In that case, we would win over the
+Hashtable in terms of the amount of GC'd memory.
+I really do not want to rely on us switching to the Thread-is-per-
+domain model. That model seems to create a plethora of differences
+with the behavior of the MS framework. the MS FX seems to leak a few
+types of objects (Thread, Type, String, CultureInfo) by design.