Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Tue, 05 Jul 2011 02:11:18 -0400 Organization: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations Lines: 35 Message-ID: References:

NNTP-Posting-Host: NcCSLBfeBDRRZ9B6cKcxGw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: WinVN 0.99.12z (x86 32bit) X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5858 On 04/07/2011 12:39 PM, BGB wrote: > On 7/1/2011 7:05 PM, Joshua Cranmer wrote: >> On 6/28/2011 10:12 PM, >> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations >> wrote: >>> If the list wasn't mutable there'd be no problem casting a >>> List_{to a List.
>>
>> And then I'd complain because my program would be spending more time
>> copying the values between immutable queues than actually doing work. As
>> long as the language has the potential for mutable collections (which
>> most people want for performance reasons), you have the potential for
>> generics casting issues.
>
> well, and probably putting more pressure on the garbage collector.

Typical immutable usage-patterns create more pressure in one single
predominant way: by producing more very-short-lived temporaries holding
intermediate values. Assuming the JIT doesn't optimize those out of the
heap altogether, they will die in edenspace which generally makes them
extremely cheap (as the gc cost to clean up edenspace is proportional
only to the number of survivors, not the number of dead objects). Where
they can be a bit less cheap is that heap space requirements to avoid
more major collections may be higher.

> a great downside of using an FP-like style with a GC and a language/VM
> that generally lacks the concept of user-defined value-types is that it
> increases the amount of garbage produced (thus increasing the number of
> GC cycles).

Don't forget that the JIT can optimize local temporary objects that
escape analysis shows never leave the method scope (or have their
identity hash code needed) into being defacto "value type" objects
instead of heap objects.}