Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why "lock" functionality is introduced for all the objects?

Reply
Thread Tools

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

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-22-2011
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

 
Reply With Quote
 
 
 
 
Henderson
Guest
Posts: n/a
 
      07-22-2011
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.
 
Reply With Quote
 
 
 
 
Volker Borchert
Guest
Posts: n/a
 
      07-22-2011
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 <(E-Mail Removed)>
"I'm a mechanic, not a doctor." Volker Borchert <(E-Mail Removed)>
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-22-2011
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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-22-2011
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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-22-2011
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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      07-22-2011
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


 
Reply With Quote
 
Alex Shabanov
Guest
Posts: n/a
 
      08-02-2011
On Jul 6, 3:56*am, Alex J <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Server 2003 SP1 introduced "enableBestFitResponseEncoding" setting =?Utf-8?B?VG9yc3RlbiBTdHVybQ==?= ASP .Net 0 08-31-2005 12:57 PM
Change in config on 1700 when firewall is introduced - HELP! Kapamarou Cisco 0 12-29-2003 05:40 PM
weird white space being introduced into <td> neverstill ASP .Net 1 12-05-2003 06:12 PM
New Exam Question Types and Testlet Exam Format to Be Introduced Petter B°rkeeiet MCSE 1 09-18-2003 02:02 PM



Advertisments