Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Tue, 28 Jun 2011 14:40:39 -0400 Organization: albasani.net Lines: 42 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.albasani.net q+BGeFbaWqRwKE26KT34sYF/JCZ7WShu3UpiRZbGcQqXKByyC8LzFH40zWzHp8UxmmyXo71Ro9eLs8XHDJ6ldmIVZGfWDa1jY8W7JRtqIBNiA7GvHUfeeGBAYFqE/pz4 NNTP-Posting-Date: Tue, 28 Jun 2011 18:40:39 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="SGmVVMeru3/fkM1RFY+MGzebc8ZJDYBWx6kwsVz5f9XcVHZOkizgQgKqSAnYQiLzP9FIeVQa5IpYqNcFOBLMMkZcvM7o9w7U4rzoCbgiWV4JoxmI2FJV+i00Qhkb+Bnz"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:D4fM6mS7gjAGEL2QueOqNDay0j8= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5743 On 06/28/2011 01:33 PM, Stefan Ram wrote: > Alex J writes: >> What do you think of it? > > I do not think, but use a web search engine and find: > > http://c2.com/cgi/wiki?JavaObjectOverheadIsRidiculous Refers to Java 1.2.2. Things have changed significantly since then, including the loss of a word from object pointers. > http://www.trevorpounds.com/blog/?p=351 > > . And here is a rationale given for why every object has a lock: > > http://forums.oracle.com/forums/thread.jspa?threadID=1140765 > > , that is, so that one can use »synchronized« on object > methods (which stands for »synchronized( this )«). It is evident that Java's design introduces overhead. Duh. But it's not the wild claim of 100% overhead. That's just stupid. How much that overhead is in practice depends on HotSpot and what idioms would be needed to replace the lost feature of inbuilt synchronization. Given that Java's design does introduce a cost, the question remains - for what benefit? We give up some memory - did we save on developer cost? Did we save on runtime crashes? Did HotSpot optimize away the unused cruft? We need to know the real numbers. How much does Java's design cost an actual program, and what would it have cost that program to have lacked that design feature? People are throwing around terms like "bloated" but only focusing on half the cost-benefit analysis, picking numbers out of their butts, and exaggerating those numbers to boot. That can only lead to suboptimal decisions. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg