Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In the famous Java Concurrency in Practice, section 2.4, it says that intrinsic locking approach, as against explicit locks was a bad design decision as its confusing and also “…it forces JVM implementors to make tradeoffs between object size and locking performance.”
Can someone please explain how object size effects locking performance?
Well since every object can be locked, this means that every object has to have enough place to store all the information we need when locking.
That’s rather unappealing because the vast, vast majority of objects will never be locked so we’re wasting lots of space. So in practice Hotspot solves this by using 2bits to record the state of the object and reusing the rest of the object header depending on these two bits.
Then there’s the whole biased/non-biased locking stuff.. well you can start reading about it here. Hotspot documentation is not what I’d call extensive, but locking and object headers are better represented than most of the rest. But in doubt: Read the source code.
PS: We have a similar problem with the native hashcode of every object too. “Just use the memory address” isn’t much good if your GC shuffles objects around. (But contrary to locking there’s no real alternative – if we want this functionality)