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

Christian Vest Hansen karmazilla at gmail.com
Sun Mar 4 15:46:33 EST 2012


The LockSupport.park methods do a similar thing with the permits, but in a
racy maner, where it is possible that a new permit is allocated even though
the free-list isn't "supposed to be" empty. According to the code comments,
things are done this way to avoid an ABA problem with the free list, IIRC.

On Sun, Mar 4, 2012 at 12:35, √iktor Ҡlang <viktor.klang at gmail.com> wrote:

> Parking threads is cheap...
> On Mar 4, 2012 12:24 PM, "William Louth (JINSPIRED.COM)" <
> william.louth at jinspired.com> wrote:
>
>>  fix a relatively small memory allocation retention problem with a
>> significant memory allocation rate problem...sounds great
>>
>> On 04/03/2012 12:05, √iktor Ҡlang wrote:
>>
>>
>>
>> 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.
>>
>>  Cheers,
>> √
>> Â
>>
>>>  Â
>>> 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
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>
>>
>>  --
>> Viktor Klang
>>
>> Akka Tech Lead
>> Typesafe <http://www.typesafe.com/>Â - The software stack for
>> applications that scale
>>
>> Twitter: @viktorklang
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120304/41578fca/attachment.html>


More information about the Concurrency-interest mailing list