Re: Why "lock" functionality is introduced for all the objects?
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