Re: Why "lock" functionality is introduced for all the objects?
Michal Kleczek wrote:
Lew wrote:
Show me the numbers. What penalty?
It is (almost) twice as much memory as it could be and twice as much GC
cycles. Almost because in real world the number of objects that you need to
Nonsense. It's an extra 4 bytes per object. Most objects are much larger
than 4 bytes, so it's far, far less than "twice as much memory".
Similarly there's no way four extra bytes per object double the number of GC
cycles.
Anyhow, when I ask you to show me the numbers, I mean real numbers, not
made-up speculative nonsense. What Java version, host, OS, configuration and
workload? What was the actual, measured, real, verified impact?
Show me the numbers.
synchronize on is way lower than the number of all objects you create.
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?
That is actually something I would like to hear as well and - as I read it -
what OP asked for - the discussion of pros and cons of different approaches
with some explanation of why it is done like this in Java.
And your answer looks like "that's the way it is and it is the best way it
can be done".
How does it look like that? How do you get to misrepresent what I say and
attribute different points to me from what I actually said?
What I actually said was the answer to the OP's question - why was it done
that way? There was a reason. Nowhere did I say or imply that it's the best
way it can be done. In fact, I explicitly disavowed that interpretation.
You're being dishonest here. Stop that.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg