Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6384

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

Show all headers | View raw

On 6/28/2011 5:29 AM, Alex J 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.
>
> 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?

For all the simple cases:

public class Foobar {
    ...
    private Object lock = new Object();
    ...
    public void test() {
        ...
        synchronized(lock) {
            ...
        }
        ...
     }
     ...
}

having to use LockingObject instead of Object would have worked fine.

But in more complex scenarios where you have multiple methods modifying
multiple objects, then the only safe way is to lock on the actual
objects (obviously in a fixed order to avoid deadlocks).

Arne

Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar

Thread

Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 20:33 -0400
  Re: Why "lock" functionality is introduced for all the objects? Patricia Shanahan <pats@acm.org> - 2011-07-21 21:08 -0700
    Re: Why "lock" functionality is introduced for all the objects? Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 10:20 -0400

csiph-web