[Mono-bugs] [Bug 27796][Nor] Changed - patch to speed to mono_class_vtable

[bugzilla-daemon@rocky.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 vargaz@freemail.hu.

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

--- shadow/27796	Mon Jul 15 13:04:11 2002
+++ shadow/27796.tmp.23092	Mon Jul 15 13:20:33 2002
@@ -48,6 +48,25 @@
 domain: a quick patch shows a 3% improvement.
 We can check if we can do something like that for the arrays, though
 the main problem is probably that the lock/unlock operations are way
 too slow and should be optimized: we use the platform layer that
 emulates the win32 critical regions. Using a simple pthread mutex
 could be worthwhile.
+
+------- Additional Comments From vargaz@freemail.hu  2002-07-15 13:20 -------
+The cached_domain field is originally 0, then it is set to a nonzero
+value _exactly once_ inside the lock, so there is no way the
+cached_vtable field can change after the conditional check.
+The current patch is wrong in this respect: the assignment to the vtable
+should be done _before_ the assignment to the domain, like this:
+
++	if (! class->cached_domain) {
++		class->cached_vtable = vt;
++		class->cached_domain = domain;
++	}
+
+
+BTW, I tried caching the string vtable in the domain structure, but
+a lot of calls are made from mono_array_new, which in turn, is called
+by a lot of the icall functions with non-constant class argument, so
+they are harder to optimise. The patch (if working) can speed up
+these calling sites as well.