«

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

On 21/07/2011 8:30 PM, Arne Vajhøj wrote:
> On 6/30/2011 6:04 PM, Tom Anderson wrote:
>> On Tue, 28 Jun 2011, Alex J wrote:
>>> The better decision, IMHO, would be to introduce lock/wait mechanics
>>> for only, say, the Lockable descendants.
>>
>> I agree with this, actually. There might be some small performance
>> improvement, but it would also make the locking behaviour of code more
>> explicit, and so clearer.
>
> Given that Java does not allow multiple inheritance then that would
> have been tough restriction.

Others suggested that Lockable could have been a marker interface with
special significance to the compiler, ala Serializable. Java allows
multiple inheritance of interfaces.

Arne Vajhøj wrote:
> Given that Java does not allow multiple inheritance

...which is about the most annoying omission...

> [ ... ]

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <>
"I'm a mechanic, not a doctor." Volker Borchert <>

On 7/22/2011 12:20 AM, Henderson wrote:
> On 21/07/2011 8:30 PM, Arne Vajhøj wrote:
>> On 6/30/2011 6:04 PM, Tom Anderson wrote:
>>> On Tue, 28 Jun 2011, Alex J wrote:
>>>> The better decision, IMHO, would be to introduce lock/wait mechanics
>>>> for only, say, the Lockable descendants.
>>>
>>> I agree with this, actually. There might be some small performance
>>> improvement, but it would also make the locking behaviour of code more
>>> explicit, and so clearer.
>>
>> Given that Java does not allow multiple inheritance then that would
>> have been tough restriction.
>
> Others suggested that Lockable could have been a marker interface with
> special significance to the compiler, ala Serializable. Java allows
> multiple inheritance of interfaces.

It could be, but does that provide any space in the data structure?

Arne

On 7/22/2011 12:39 AM, Volker Borchert wrote:
> Arne Vajhøj wrote:
>> Given that Java does not allow multiple inheritance
>
> ..which is about the most annoying omission...

Well - SUN did not think so and when MS had to do .NET and C# they
did not think so.

Sure SUN and MS could be wrong, but there must be some merit to
omitting it.

Arne

On 7/22/2011 12:08 AM, Patricia Shanahan wrote:
> On 7/21/2011 5:33 PM, Arne Vajhøj wrote:
> ...
>> 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).
>
> I'm not sure how that would have worked for synchronized methods, as
> distinct from synchronized blocks.

It does not.

Synchronized methods are only for the simple cases.

Arne

On 7/22/2011 12:30 PM, Patricia Shanahan wrote:
> On 7/22/2011 7:17 AM, Arne Vajhøj wrote:
>> On 7/22/2011 12:20 AM, Henderson wrote:
>>> On 21/07/2011 8:30 PM, Arne Vajhøj wrote:
>>>> On 6/30/2011 6:04 PM, Tom Anderson wrote:
>>>>> On Tue, 28 Jun 2011, Alex J wrote:
>>>>>> The better decision, IMHO, would be to introduce lock/wait mechanics
>>>>>> for only, say, the Lockable descendants.
>>>>>
>>>>> I agree with this, actually. There might be some small performance
>>>>> improvement, but it would also make the locking behaviour of code more
>>>>> explicit, and so clearer.
>>>>
>>>> Given that Java does not allow multiple inheritance then that would
>>>> have been tough restriction.
>>>
>>> Others suggested that Lockable could have been a marker interface with
>>> special significance to the compiler, ala Serializable. Java allows
>>> multiple inheritance of interfaces.
>>
>> It could be, but does that provide any space in the data structure?
>
> Compiler magic. Just as the compiler reacts the lack of any constructor
> by generating a default constructor, it would react to the Lockable
> interface by generating a field to contain the lock data.

It is possible.

I am not a big fan of that type of magic, but it is possible.

Arne

On Jul 6, 3:56*am, Alex J <vstren...@gmail.com> wrote:
>...
> Keeping in mind the difference C vs Java implementation I can only
> speculate on how muchlockfunctionalitycontributes to that overhead.

BTW, if someone is still interested in the overhead:

$ANDROID_SOURCES/dalvik/vm/oo/Object.h introduces the following layout
behind the Object class:

typedef struct Object {
/* ptr to class object */
ClassObject* clazz;

/*
* A word containing either a "thin" lock or a "fat" monitor. See
* the comments in Sync.c for a description of its layout.
*/
u4 lock;
} Object;

So the memory overhead is known (and it is +4 bytes for all the
Objects no matter if they ever locked or not).

As for HotSpot JVM it is not that easy to find the distinctive layout
of the Object class.

>
> [snip]
> > --
> > Lew
> > Honi soit qui mal y pense.http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg