[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.