Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!postnews.google.com!r2g2000vbj.googlegroups.com!not-for-mail From: Alex J Newsgroups: comp.lang.java.programmer Subject: Why "lock" functionality is introduced for all the objects? Date: Tue, 28 Jun 2011 02:29:07 -0700 (PDT) Organization: http://groups.google.com Lines: 17 Message-ID: NNTP-Posting-Host: 94.25.210.15 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1309255771 15810 127.0.0.1 (28 Jun 2011 10:09:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 28 Jun 2011 10:09:31 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r2g2000vbj.googlegroups.com; posting-host=94.25.210.15; posting-account=WEhrTAoAAACB_dCNiMk-LATj1SOnQi04 User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HNKRUAELSC X-HTTP-UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.30 (KHTML, like Gecko) Ubuntu/11.04 Chromium/12.0.742.91 Chrome/12.0.742.91 Safari/534.30,gzip(gfe) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5724 I'm curious why Java designers once decided to allow every object to be lockable (i.e. allow using lock on those). 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. The better decision, IMHO, would be to introduce lock/wait mechanics for only, say, the Lockable descendants. The current approach seems to be very simple, but is the performance penalty so small for not be taken into an account? Eclipse uses tons of small objects and I guess that is why it consumes so much memory while a significant part of it is never used. What do you think of it?