[concurrency-interest] regarding synchronized command and object'sfootprint
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.
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...
More information about the Concurrency-interest