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, 28 Jun 2011 14:23:12 -0400 Organization: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations Lines: 40 Message-ID: References: NNTP-Posting-Host: quLqbYjFExRqcR6wI1lYGQ.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:5741 On 28/06/2011 2:13 PM, Lew wrote: > Michal Kleczek wrote: >> Lew wrote: >>> Show me the numbers. What penalty? >> >> It is (almost) twice as much memory as it could be and twice as much GC >> cycles. Almost because in real world the number of objects that you >> need to > > Nonsense. It's an extra 4 bytes per object. Most objects are much larger > than 4 bytes, Bullpuckey, other than that a nontrivial object is always at least 12 bytes due to Java's bloated object headers plus alignment. Ignoring that, it's quite common to have lots of small objects at runtime -- from boxed primitives (4 bytes for most and 8 bytes for Longs and Doubles, plus object headers) to short strings (two bytes per character plus four for the length field = 8 for a two-letter word and 4 for an empty string -- again, plus object headers) and the occasional content-free pure-behavior object (abstract factories, strategy pattern implementations, event listeners, plus most of the things you'd use an anonymous inner class for ...). Small collections are a bit larger but an 8 byte object header is still likely to be a fair percentage; and their iterators may contain as little as a single integer index plus a single pointer (ArrayList's likely does) and so be the same size as a Long or a Double. And then there's all the objects with one or two reference type fields. Four bytes each, on a 32-bit JVM. You can't count the "nested" objects' own sizes, because they each have their own object header. Objects with many fields are quite a bit rarer than ones with only one or two fields. *Classes* with many fields are less common, and usually there will be fewer live instances at runtime. Ultimately, overhead fraction = average bytes directly in fields (at most 4 for most fields on 32-bit systems, excepting long and double primitive fields) divided by header size, where the average is over a *typical population of live objects in a running system* rather than over a set of, say, classes in use in a system.