Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: KitKat Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Fri, 01 Jul 2011 18:08:34 -0400 Organization: Nestle Lines: 66 Message-ID: References: NNTP-Posting-Host: 4/raLmFi1848LMFwwllsmA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: WinVN 0.99.12z (x86 32bit) X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5814 On 01/07/2011 4:40 PM, Tom Anderson wrote: > On Thu, 30 Jun 2011, KitKat wrote: > >> Are you sure that last one was a "chap"? "Tamiya" sounds rather >> feminine to me. > > Perhaps - and a quick google reveals that it is a girl's name in Hebrew. > However, in Japanese, i believe it's a family name, and that Tamiya > Onodera is Dr Tamiya's name written in the normal Japanese order, > putting his family name first. Although i could be wrong. ??? Regardless of which, "Onodera" also sounds feminine. > The object's identity hash is shuffled between the object and its lock > according to whether it has an expanded lock or not. That would work, if that's what the second word in the object header normally is. Assuming it's the heap address at time of creation, and objects are aligned on word boundaries, the two least order bits of the identity hash are going to be zero, so you can use those bits for something else and mask them off to get the hash. On the other hand, that suggests a way to make object headers of only *one* word. Consider: how likely are we to have four billion vtables in a running 32-bit JVM? Let alone Long.MAX_VALUE - Long.MIN_VALUE + 1 in a 64-bit one? Reserve a low chunk of the address space (and call it part of permgen?) for vtables and your vtable pointers get quite short. The vtable pointer plus a few bits of the object's initial address would still make a pretty decent identity hash for collections with heterogeneous keys; homogeneous keys, in my experience, are usually value objects with overridden hashCode such as Strings and you can make the initial-address-bits (and the thin lock bit) the low order bits. Shift right one bit to lose the lock bit and have the hash; shift right n bits for some fairly small n to get the vtable pointer. Vtable lookup is a tiny bit slower due to a test of the lock bit plus one added shift instruction on each lookup, but the critical performance points tend to get JITted into direct calls or branch-predictable is-it-a-Foo? jump-or-normal-vtable-lookup choices. And the vast majority of production Java code is I/O bound anyway. Well, except when the object needs a fat lock. Then the whole word becomes a pointer to a structure that points to the vtable and contains the lock and identity hash. Now vtable lookup has an added indirection. But the bottleneck with such objects will usually be contention for the lock itself, not CPU cycles. > That might be memory-efficient, but it would not be at all > time-efficient, as it would require a map lookup to lock an object. Map lookups are O(1) and a low level implementation in C built into the JVM would boil down to masking and shifting the hash and then a pointer addition and dereference, only needed when you wanted to lock or unlock an object -- and again, the time spent on this will be dwarfed by the time spent in contention for the lock anyway, fairly often. Branch prediction and pipelining might help in the case of high-CPU areas that lock an object with low contention, in that some of the work might proceed in parallel with lock acquisition in the absence of contention (though, only as far as work that can be done in cache or registers, since the lock must be held prior to any memory reads or writes in the guarded object, and on initial acquisition failure that work may have to be repeated later on acquisitoon).