21

As a C++ programmer becoming more familiar with Java, it's a little odd to me to see language level support for locking on arbitrary objects without any kind of declaration that the object supports such locking. Creating mutexes for every object seems like a heavy cost to be automatically opted into. Besides memory usage, mutexes are an OS limited resource on some platforms. You could spin lock if mutexes aren't available but the performance characteristics of that are significantly different, which I would expect to hurt predictability.

Is the JVM smart enough in all cases to recognize that a particular object will never be the target of the synchronized keyword and thus avoid creating the mutex? The mutexes could be created lazily, but that poses a bootstrapping problem that itself necessitates a mutex, and even if that were worked around I assume there's still going to be some overhead for tracking whether a mutex has already been created or not. So I assume if such an optimization is possible, it must be done at compile time or startup. In C++ such an optimization would not be possible due to the compilation model (you couldn't know if the lock for an object was going to be used across library boundaries), but I don't know enough about Java's compilation and linking to know if the same limitations apply.

Joseph Garvin
  • 20,727
  • 18
  • 94
  • 165
  • I'm pretty sure `synchronized` is handled internally in the JVM, rather than relying on OS-level resources. – Anon. Dec 14 '09 at 00:40
  • 1
    That can't fully be true. I do agree that it can be implemented any way the JVM wants, but the JVM must necessarily be relying on OS-level communication somewhere internally. You can write your own mutex class that spin locks, but if you want the OS scheduler to put threads to sleep and wake them up appropriately, at some point you have to tell the OS about your mutex, and those sort of registrations are the limited resource. – Joseph Garvin Dec 14 '09 at 00:45
  • You don't need to tell the OS about your mutex - you just need to tell it when certain threads need to be woken up. – Anon. Dec 14 '09 at 00:47
  • Good point, if the OS provides a way for a thread to directly signal another thread to resume, the JVM could use that capability instead. But AFAIK applications always implement that functionality in terms of semaphores. – Joseph Garvin Dec 14 '09 at 01:02

4 Answers4

17

Speaking as someone who has looked at the way that some JVMs implement locks ...

The normal approach is to start out with a couple of reserved bits in the object's header word. If the object is never locked, or if it is locked but there is no contention it stays that way. If and when contention occurs on a locked object, the JVM inflates the lock into a full-blown mutex data structure, and it stays that way for the lifetime of the object.

EDIT - I just noticed that the OP was talking about OS-supported mutexes. In the examples that I've looked at, the uninflated mutexes were implemented directly using CAS instructions and the like, rather than using pthread library functions, etc.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • By inflate, do you mean something is going on like the small string optimization in C/C++? (http://tulrich.com/rants-2009.html#d2009-01-03T00:00:00Z) Basically, that the information starts as bits packed inside a word, but when certain conditions are met that word starts to be interpreted as a pointer to an object with more fields? – Joseph Garvin Dec 14 '09 at 00:54
  • 2
    Using only CAS instructions, how do you get the OS scheduler to put a thread to sleep? – Joseph Garvin Dec 22 '09 at 20:52
  • 1
    @JosephGarvin - you don't. You only use CAS to acquire / release the lock in the uninflated / uncontended case. If contention is detected, the locking/unlocking code would then do the relevant thread scheduling syscalls ... or whatever. – Stephen C Apr 28 '13 at 04:03
2

You can never be sure that an object will never be used as a lock (consider reflection). Typically every object has a header with some bits dedicated to the lock. It is possible to implement it such that the header is only added as needed, but that gets a bit complicated and you probably need some header anyway (class (equivalent of "vtbl" and allocation size in C++), hash code and garbage collection).

Here's a wiki page on the implementation of synchronisation in the OpenJDK.

(In my opinion, adding a lock to every object was a mistake.)

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
  • Is there somewhere I can read more about this 'header'? Since you say you'd probably need it anyway I assume it's used for things other than locking. – Joseph Garvin Dec 14 '09 at 00:39
  • It's all in the GPL/JRL/JIUL source! – Tom Hawtin - tackline Dec 14 '09 at 00:41
  • True, but I was hoping that if Java programmers in general are interested in the answers to these questions I'd assume someone has written up something more easily digestible than millions of lines of source code. If I become interested enough and have enough time I could do that eventually though ;) – Joseph Garvin Dec 14 '09 at 00:46
  • Java programmers are not interested:) It's designed for lazy people anyway. As long as you understand the semantics, and the program runs fairly well, nobody cares what's under the hood... – irreputable Dec 14 '09 at 01:36
  • Great link! It explains why Java 6 locking is so much faster. Precisely what I was looking for! – Robert Jack Will Dec 08 '12 at 20:17
  • The cited URL now redirects to an Oracle marketing page, this link may suffice for those who were curious about the content that @TomHawtin-tackline had linked: https://wiki.openjdk.java.net/display/HotSpot/Synchronization – maxm Oct 09 '19 at 06:50
2

This is really an implementation detail of the JVM, and different JVMs may implement it differently. However, it is definitely not something that can be optimized at compile time, since Java links at runtime, and this it is possible for previously unknown code to get a hold of an object created in older code and start synchronizing on it.

Note that in Java lingo, the synchronization primitive is called "monitor" rather than mutex, and it is supported by special bytecode operations. There's a rather detailed explanation here.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
1

can't JVM use compare-and-swap instruction directly? let's say each object has a field lockingThreadId storing the id of the thread that is locking it, 

while( compare_and_swap (obj.lockingThreadId, null, thisThreadId) != thisTheadId )
    // failed, someone else got it
    mark this thread as waiting on obj.
    shelf this thead

//out of loop. now this thread locked the object

do the work

obj.lockingThreadId = null;
wake up threads waiting on the obj

this is a toy model, but it doesn't seem too expensive, and does no rely on OS.

irreputable
  • 44,725
  • 9
  • 65
  • 93
  • 1
    P.S. the design choice of allowing any objects to be locked is probably wrong. maybe only certain type of objects should be allowed for sync purpose, just like only certain type of objects can be thrown. `synchronized(a_normal_object){}` is very confusing to new learners, they thought the object is thus protected and no other thread can write to it. if they have to use a different lock object to protect their normal object, it would be easier to understand what's going on. – irreputable Dec 14 '09 at 01:31
  • 1
    The JVM has to communicate with the OS at some point in order to get the thread to go to sleep and to be able to wake it back up again, because the OS scheduler is responsible for that. If the JVM uses it directly, all waits would be spin locks, which are inefficient for long waits. A real implementation probably does spin for a bit then goes to sleep on a real semaphore from the OS. – Joseph Garvin Dec 14 '09 at 02:12
  • "If the JVM uses it directly" <-- by 'it' I meant the CAS instruction – Joseph Garvin Dec 14 '09 at 02:12
  • of course the heavy part is thread switching and it could be OS threads. but your original question is about millions of objects that can be locked and wondering how can that scale. as the toy model shows, there is no penalty at all for objects that are not locked. – irreputable Dec 14 '09 at 03:12