Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!plix.pl!newsfeed1.plix.pl!news.icm.edu.pl!news.onet.pl!.POSTED!not-for-mail From: Michal Kleczek Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Tue, 28 Jun 2011 18:41:40 +0200 Organization: http://onet.pl Lines: 53 Message-ID: References: NNTP-Posting-Host: 77-255-242-115.adsl.inetia.pl Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: news.onet.pl 1309279299 2683 77.255.242.115 (28 Jun 2011 16:41:39 GMT) X-Complaints-To: niusy@onet.pl NNTP-Posting-Date: Tue, 28 Jun 2011 16:41:39 +0000 (UTC) User-Agent: KNode/4.4.10 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5734 Lew wrote: > Alex J wrote: >> I'm curious why Java designers once decided to allow every object to >> be lockable (i.e. [sic] allow using lock on those). > > Because that makes it possible to do concurrent programming intrinsically. > Could you elaborate more on that? Do you mean there is no other way to do it? I find this question quite intriguing as well since it looks quite useless for example to be able to lock on java.lang.Integer instance (and it is strange for me that java.lang.Integer instance occupies much more memory as int). Surely a compromise must have been done taking into account various language features ("synchronized" keyword, lack of multiple inheritance, lack of closures) - but I am not that knowlegeable enough to explain this compromise in detail. >> I know, that out of such a design decision every Java object contain >> lock index, i.e. new Object() results in allocation of at least 8 >> bytes where 4 bytes is object index and 4 bytes is lock index on 32- >> bit JVM. >> I think that it just inefficient waste of space, because not all the >> objects requires to be lockable/waitable. > > Well, that's your opinion. > It is not only his opinion - the size of object header is important especially on memory constrained devices. But not only - there is a reason why UseCompressedOops flag was introduced in 64 bit HotSpot JVM. >> The better decision, IMHO, would be to introduce lock/wait mechanics >> for only, say, the Lockable descendants. > > Oh, yeah, your opinion is humble. > >> The current approach seems to be very simple, but is the performance >> penalty so small for not be taken into an account? > > Yes. Nonexistent, really. > I wouldn't say so - see: http://wikis.sun.com/display/HotSpotInternals/CompressedOops Especially the sentence: "Memory is pretty cheap, but these days bandwidth and cache is in short supply" -- Michal