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

David Holmes davidcholmes at aapt.net.au
Sun Mar 4 16:17:58 EST 2012


In a well designed server it should be significantly less. The number of
active monitors depends on the interval between safepoints as well. In
theory you only need as many inflated monitors as there are threads in the
system, but because reclamation is not instantaneous ( a good thing to avoid
ping-pong effects) this number will be larger. There are a number of tuning
knobs for this code, and two different strategies for reclamation. You can
use -XX:+TraceMonitorInflation to see when inflation/deflation occurs. See
synchronizer.cpp for all the gory details.

David
  -----Original Message-----
  From: Yechiel Feffer [mailto:yechielf at gigaspaces.com]
  Sent: Sunday, 4 March 2012 9:24 PM
  To: dholmes at ieee.org; Concurrency-interest at cs.oswego.edu
  Subject: RE: [concurrency-interest] regarding synchronized command and
object'sfootprint


  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]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

    Hi

    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 ?



    Regards

    Yechiel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120305/db5f73a3/attachment-0001.html>


More information about the Concurrency-interest mailing list