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


Groups > comp.lang.java.machine > #15

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

From Barb Knox <see@sig.below>
Newsgroups comp.lang.java.machine
Subject Re: Why "lock" functionality is introduced for all the objects?
Date 2011-06-30 18:11 +1200
Organization I'm not unemployed; I'm a consultant
Message-ID <see-8D9973.18112630062011@news.eternal-september.org> (permalink)
References <736a142e-85ae-4790-a1f1-afb09bfed755@em7g2000vbb.googlegroups.com>

Show all headers | View raw


In article 
<736a142e-85ae-4790-a1f1-afb09bfed755@em7g2000vbb.googlegroups.com>,
 Alex J <vstrength@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?

-- 
---------------------------
|  BBB                b    \     Barbara at LivingHistory stop co stop uk
|  B  B   aa     rrr  b     |
|  BBB   a  a   r     bbb   |    Quidquid latine dictum sit,
|  B  B  a  a   r     b  b  |    altum videtur.
|  BBB    aa a  r     bbb   |   
-----------------------------

Back to comp.lang.java.machine | Previous | NextPrevious in thread | Find similar


Thread

Why "lock" functionality is introduced for all the objects? Alex J <vstrength@gmail.com> - 2011-06-28 02:30 -0700
  Re: Why "lock" functionality is introduced for all the objects? Roedy Green <see_website@mindprod.com.invalid> - 2011-06-28 10:02 -0700
  Re: Why "lock" functionality is introduced for all the objects? Barb Knox <see@sig.below> - 2011-06-30 18:11 +1200

csiph-web