• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (7)

1 Nasser Ebrahim commented Permalink

Guru, the information is good.

 
You have explained when the lock is inflated and deflated but not the need of inflation.
 
It is better if you explain why inflation is required when the lock is contended for long time.

2 ggchaitanya commented Permalink

I have not realised that i missed this point.

 
As mentioned earlier, the inflation happens when there is lock contention. When there is lock contention, there could be multiple threads that could be waiting on a particular lock. The 32 bit flag is not capable of holding all that information. So we create a JVM system monitor structure that holds all this information. We continue to spin, though, for performance gains.
 
Same thing applies for the reason behind why we inflate, when we start wait/notify on a lock.

3 JavinPaul commented Permalink

Nice post

4 skyrim commented Permalink

It's a good post.

 
I have another question.
Is there any different between "synchronized" and "java.util.concurrent.locks.*lock" on for J9?

5 ggchaitanya commented Permalink

Yuan,
synchronized primarily represent the locking features that mimic OS's structures like mutex and semaphores.
"java.util.concurrent.locks.*" represent higher level locking mechanisms to help with various application scenarios. These locks are internally built created using the Object locks.

6 ggchaitanya commented Permalink

Was just pointed to a mistake in my comment.
java.util.concurrent.* locks may not necessarily be built using the Object locks.

7 commented Trackback

[Trackback] very handful of internet websites that occur to be in depth beneath, from our point of view are undoubtedly nicely really worth checking out

Add a Comment Add a Comment