[concurrency-interest] regarding synchronized command and object'sfootprint

Yechiel Feffer yechielf at gigaspaces.com
Sun Mar 4 06:23:37 EST 2012

So its not so bad- meaning the number of such monitors in the system =  maximum number of concurrent synchronized objects  since the jvm started. This cannot be more than several thousands  even for a very busy server.

From: David Holmes [mailto:davidcholmes at aapt.net.au]
Sent: יום א 04 מרץ 2012 12:50
To: Yechiel Feffer; Concurrency-interest at cs.oswego.edu
Subject: RE: [concurrency-interest] regarding synchronized command and object'sfootprint

That is correct in Hotspot. If contention occurs a heavyweight monitor has to be created (this is called monitor inflation). There is a freelist of inflated monitors - if the list is non-empty then one of those monitors is used, else a new one is created.  If the monitor becomes idle it can be returned to the freelist during a safepoint. The monitors once created are never destroyed.

It has nothing to do with "barrier info" whatever that might be.

David Holmes

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu<mailto:concurrency-interest-bounces at cs.oswego.edu> [mailto:concurrency-interest-bounces at cs.oswego.edu]<mailto:[mailto:concurrency-interest-bounces at cs.oswego.edu]>On Behalf Of Yechiel Feffer
Sent: Sunday, 4 March 2012 7:56 PM
To: 'Concurrency-interest at cs.oswego.edu'
Subject: [concurrency-interest] regarding synchronized command and object'sfootprint
I heard a claim that execution of synchronized(object)  command  (maybe contended synchronized) raises the  object footprint in the java heap- a raise the (partially ?) remains even after all threads exited the synchronized block.
Is it correct ? Is it related to barrier info java maintains ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120304/6b2cd9f0/attachment.html>

More information about the Concurrency-interest mailing list