[Mono-bugs] [Bug 65414][Nor] Changed - [PATCH] Thread Local Data Slots do not survive nested appdomain transitions

[bugzilla-daemon@bugzilla.ximian.com]

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 bmaurer@users.sf.net.

http://bugzilla.ximian.com/show_bug.cgi?id=65414

--- 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 bmaurer@users.sf.net  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.