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 13:10:28 -0400 Organization: albasani.net Lines: 101 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net w+wVWrdRzNoaDmmdE6jEQJcFWCm3DjpYSotZMad3OE4IY4d+tZlZA45okWKWYewSHMA1ZOXpcXUpgjZjMREKvcxsJkxY68da3Ps4v4krz7bihkfkEFBc04gYueunhfox NNTP-Posting-Date: Tue, 28 Jun 2011 17:10:29 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="IgyI11hBV5XffhQ8BTtoUYxofGOSqh95CK1KM6avLftOuYnATv6gcrkyGkAd0aaFhV2pDEBa0fgzRh/Y1oxKVZCR1hAsfe3OG+Bui0UZPC3puZBeLVmOLpOlzPvIH9Wk"; 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:0BUJGgmRvZfDXfXjsLf7EdsiXKg= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5736 On 06/28/2011 12:41 PM, Michal Kleczek wrote: > 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? No, I don't mean that, and I don't see how it follows from what I said. To elaborate, building monitors into 'Object' (and perforce its descendants) means that multi-threaded programming is intrinsic, that is, built in to the very nature of objects in Java. This makes the simple case for synchronization, well, simple. You create an object of arbitrary type and you can use it as a lock (strictly speaking, a Hoare monitor). This means that any class can achieve a measure of thread safety by the proper use of 'synchronized (this)' or the implicit equivalents. The idiom is pervasive and extremely useful in Java. It is arguably one of the key aspects to Java's success as a language. > 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 So don't lock on an Integer instance, then. > strange for me that java.lang.Integer instance occupies much more memory as "strange"? Based on what? 'int' is a primitive, available for convenience because primitives are so useful without the overhead of objectness. That might not be an optimal decision, although many successful languages have made the same choice. (C, C++, C#, Java.) Given the long history of languages with the same dichotomy, I find it strange that you find it strange. > 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. Java's supposed "lack" of closures, given the admittedly more verbose alternatives that actually do exist, poses little if any problem. Java does allow multiple inheritance of contract, just not of implementation, and actually that distinction makes for clean, elegant code. The 'synchronized' keyword depends for its utility on the very feature in dispute in this thread, namely the presence of a monitor in every object. Far from being a compromise, this is a key strength of the Java language. >>> 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. OK, that's your opinion, too. >>> 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" Show me the numbers. What penalty? Compared to what instead? If you give up a feature, you have to add it some other way - what would be the inefficiency of Java's approach compared to the alternative? And give us some measurements to support the claim of any "penalty". Don't forget that HotSpot saves memory as well as increases speed, depending ont he optimizations involved at any given moment. Have you taken that into consideration? -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg