[M3devel] up-front initialization of mutex/conditionvariable?

Tue Dec 15 05:47:33 CET 2009

Yes HotSpot.

I guess I should look at others and JITed code.

C# too.

So, question..Java probably has to perf because people probably abuse it. They have to counteract deficiencies elsewhere.

Similar for us?

Granted, I removed the win32 thread cache. And there was a criticalsection cache in the past.

No function call or interlock in uncontended is impressive..you could do that based on the Hotspot code..but is it worth..the inlining bloat and "dependencies" (changes requiring recompiling clients).

The gcc backend does work on Windows. In a fashion, a fairly practical fashion.

With "mingw" you can just go and configure && make and you get a gcc that doesn't use cygwin.

I'm more interested in improving the fast integrated one, or maybe llvm support.

Something that writes out .obj files and doesn't require so many processes.

Debugging is a mixed story too. Integrated backend outputs only function symbols and line number. Nothing for locals or types. gcc output I believe debuggable only with gdb, at least the cygwin gcc.

We can get CAS et. al. without resorting to gcc.

As a function call or probably inline.

I think that locks in a dependency on newer processors and/or operating systems though.

If the integrated backend is missing CAS and that is holding you up, speak up.

The integrated backend is just incredibly faster than the gcc backend, both to build and run.

 - Jay

> Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable?
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Dec 2009 23:26:43 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> We need an compiler intrinsic CAS to avoid calls. More incentive to get the gcc-based backend working on Windows?
> I'll bet most modern Java implementations destroy thread libraries on performance. In the uncontended case they have no atomic operations, and the code is all inline. I'm not sure what Java implementation you are looking at... (Hotspot's sucks BTW).
> 
> On 14 Dec 2009, at 23:04, Jay K wrote:
> 
> > Is it possible to do on Win32?
> > Win32 critical sections are cheap and already probably work roughly "that way".
> > Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap.
> > 
> > Our (new) win32 condition variables are not cheap, but similar in cost to Java.
> > (Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.)
> > 
> > - Jay
> > 
> > 
> > > Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable?
> > > From: hosking at cs.purdue.edu
> > > Date: Mon, 14 Dec 2009 22:49:48 -0500
> > > CC: m3devel at elegosoft.com
> > > To: jay.krell at cornell.edu
> > > 
> > > We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to:
> > > 
> > > Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258–268. Montre ́al, Canada (Jun 1998)
> > > 
> > > Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot
> > > 
> > > Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79–90. Monterey, Califor! nia (Apr 2001),http://www.usenix.org/publications/library/proceedings/jvm01/dice.html
> > > 
> > > Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479–495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf
> > > 
> > > Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130–141. Seattle, Washington (Nov 2002)
> > > 
> > > Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223–237. Denver, Colorado (Nov 1999)
> > > 
> > > Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559–583. No. 3086! in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 200 4)
> > > 
> > > Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263–272. Portland, Oregon (Oct 2006)
> > > 
> > > On 14 Dec 2009, at 22:06, Jay K wrote:
> > > 
> > > > Is it possible to initialize mutexes and condition variables right away?
> > > > Instead of having the delayed initialization?
> > > > 
> > > > 
> > > > Mutex initialization is pretty fast on Windows, no syscall.
> > > > Having it be delayed like it is maybe isn't worthwhile.
> > > > 
> > > > 
> > > > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ?
> > > > 
> > > > 
> > > > I know there is the idiom NEW(T).init() but that is up to call! ers to adhere to.
> > > > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess.
> > > > 
> > > > 
> > > > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init?
> > > > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete.
> > > > 
> > > > 
> > > > - Jay
> > > > 
> > > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091215/ec06106e/attachment-0002.html>