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

David Holmes davidcholmes at aapt.net.au
Sun Mar 4 05:49:59 EST 2012

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]On Behalf Of Yechiel
Sent: Sunday, 4 March 2012 7:56 PM
To: 'Concurrency-interest at cs.oswego.edu'
Subject: [concurrency-interest] regarding synchronized command and


  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/49822bab/attachment.html>

More information about the Concurrency-interest mailing list