[Mono-bugs] [Bug 35041][Wis] New - need lightweight monitor implementation

bugzilla-daemon@rocky.ximian.com bugzilla-daemon@rocky.ximian.com
4 Dec 2002 12:29:22 -0000


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 lupus@ximian.com.

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

--- shadow/35041	Wed Dec  4 07:29:22 2002
+++ shadow/35041.tmp.20326	Wed Dec  4 07:29:22 2002
@@ -0,0 +1,44 @@
+Bug#: 35041
+Product: Mono/Runtime
+Version: unspecified
+OS: other
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: lupus@ximian.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: need lightweight monitor implementation
+
+Currently the monitor code used to implement lock(object) {}
+is slow: we need to speed up it in the uncontended case.
+Ideas from http://www.kaffe.org/doc/kaffe/FAQ.locks
+http://www.usenix.org/events/jvm01/dice.html and I'm sure more googling
+will turn up more interesting papers.
+This microbenchmark is more than 10 times slower in mono than in some
+unnamed competitor runtime:
+class T {
+        static void Main() {
+                int a = 0;
+                T t = new T ();
+                for (int i= 0; i < 2000000; ++i) {
+                        lock (typeof(T)) {
+                                a++;
+                        }
+                }
+        }
+}
+
+See also bug http://bugzilla.ximian.com/show_bug.cgi?id=34963
+for a related issue (in the fast case we should not need to create handles
+at all).
+
+Once the fast monitor implementation is done, we'll have the jit inline the
+fast path code, but having it all in the icall should be fine and make the
+above code run significantly faster.