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

David Dice david.dice at gmail.com
Sun Mar 4 16:38:01 EST 2012


Message: 5
> Date: Mon, 5 Mar 2012 07:17:58 +1000
> From: "David Holmes" <davidcholmes at aapt.net.au>
> To: "Yechiel Feffer" <yechielf at gigaspaces.com>,
>        <Concurrency-interest at cs.oswego.edu>
> Subject: Re: [concurrency-interest] regarding synchronized command and
>        object'sfootprint
> Message-ID: <NFBBKALFDCPFIDBNKAPCGEHJJDAA.davidcholmes at aapt.net.au>
> Content-Type: text/plain; charset="windows-1255"
>
> 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.
>
>
Following up, the objectmonitor structure is a normal C++ object and
doesn't reside in the normal heap.    The lifecycle is such that we inflate
on initial contention (and a few other conditions) and, if the object is
uncontended and there are no wait()ers, we deflate at the next
stop-the-world safepoint, at which point the objectmonitor is eligible for
re-use.   Currently, the memory underlying objectmonitor instances is
type-stable.    To avoid contention on the main objectmonitor free list we
also have bounded per-thread free lists.   That can increase the # of
objectmonitors in circulation at any given time, but it's a good trade-off.
  In recent JVMs there's also a back-pressure facility where we can induce
a GC as the number of extant monitors passes a configurable bound.

Regards
Dave

p.s., other JVMs deflate on-the-fly instead of at the next safepoint.
On-the-fly is arguably better, but hotspot has a good deal of day-one code
that assumes the object:monitor relationship is stable except over
safepoints.   Even with on-the-fly deflation, we'd still need to reduce
contention on the central free lists with per-thread free lists.   And with
on-the-fly we have to worry about the case where monitors migrate between
threads, which we found was quite common.    In that case we need to take
actions to trim the free lists.   Still, on-the-fly remains better because
it decouples the synchronization subsystem from the safepointing mechanism.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120304/2313b308/attachment.html>


More information about the Concurrency-interest mailing list