Why "lock" functionality is introduced for all the objects?

Alex J

unread,

Jun 28, 2011, 5:30:17 AM6/28/11

to

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?

Roedy Green

unread,

Jun 28, 2011, 1:02:24 PM6/28/11

to

On Tue, 28 Jun 2011 02:30:17 -0700 (PDT), Alex J <vstr...@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>I'm curious why Java designers once decided to allow every object to
>be lockable (i.e. allow using lock on those).

The alternative would be to insist that objects to be locked implement
a Lockable interface. Then you would need two versions of every
class, because potentially everything is lockable.
--
Roedy Green Canadian Mind Products
http://mindprod.com
One of the curses of the computer age is manufacturers now design
home appliances to die on the very day the warranty expires.
It is deliberate waste in the service of mindless profit.

Barb Knox

unread,

Jun 30, 2011, 2:11:26 AM6/30/11

to

In article
<736a142e-85ae-4790...@em7g2000vbb.googlegroups.com>,
Alex J <vstr...@gmail.com> wrote:

> 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.

Some implementations use only 4 bytes, with one bit of that being a
flag. If the flag is 0 (the usual case) then the 4 bytes is a pointer
to the object's runtime class data (for method despatch and static
fields). If the flag is 1 then the 4 bytes is a pointer to a small
auxiliary structure which contains the pointer to the runtime class
data, the lock info, and maybe the object's hashcode (in implementations
which allow objects to be moved by the GC, which means that the object's
address can not be used as the hashcode).

To avoid having to test the flag bit every for every access to the
runtime class data, the first 4 bytes of the class data can be a pointer
to itself. Then object** (in C terms) is always a pointer to the class
data. This does cost 1 extra memory access, but it saves the extra 4
bytes per simple object.

> 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?