Re: Why "lock" functionality is introduced for all the objects?
On 06/28/2011 01:33 PM, Stefan Ram wrote:
Alex J<email@example.com> writes:
What do you think of it?
I do not think, but use a web search engine and find:
Refers to Java 1.2.2. Things have changed significantly since then, including
the loss of a word from object pointers.
. And here is a rationale given for why every object has a lock:
, that is, so that one can use ??synchronized?? on object
methods (which stands for ??synchronized( this )??).
It is evident that Java's design introduces overhead. Duh. But it's not the
wild claim of 100% overhead. That's just stupid.
How much that overhead is in practice depends on HotSpot and what idioms would
be needed to replace the lost feature of inbuilt synchronization.
Given that Java's design does introduce a cost, the question remains - for
what benefit? We give up some memory - did we save on developer cost? Did we
save on runtime crashes? Did HotSpot optimize away the unused cruft?
We need to know the real numbers. How much does Java's design cost an actual
program, and what would it have cost that program to have lacked that design
People are throwing around terms like "bloated" but only focusing on half the
cost-benefit analysis, picking numbers out of their butts, and exaggerating
those numbers to boot. That can only lead to suboptimal decisions.
Honi soit qui mal y pense.