[concurrency-interest] regarding synchronized command and object'sfootprint
viktor.klang at gmail.com
Sun Mar 4 06:05:46 EST 2012
On Sun, Mar 4, 2012 at 11:49 AM, David Holmes <davidcholmes at aapt.net.au>wrote:
> 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.
Another very good reason to stick to CAS unless the exact semantics of
synchronized is desirable. But technically, if sequential access is
desired, one can still avoid synchronization by switching to the correct
model for that - actors.
> 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
> 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 ? ****
> ** **
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest