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: Thu, 30 Jun 2011 20:17:04 -0400 Organization: Nestle Lines: 27 Message-ID: References: NNTP-Posting-Host: sVU5oalDgoYYKaoZo9xviQ.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:5804 On 30/06/2011 8:05 PM, Patricia Shanahan wrote: > On 6/30/2011 3:29 PM, KitKat wrote: >> On 30/06/2011 6:04 PM, Tom Anderson wrote: > ... >>> The details are described quite clearly in the papers, but the upshot is >>> that an object is created with neither a lock nor a slot for a lock >>> pointer (and so only a two-word header), and the lock is allocated only >>> when needed, and then wired in. Some fancy footwork means that the >>> object doesn't need to grow a pointer when this happens; the header >>> remains two words, at the expense of some slight awkwardness elsewhere. >> >> Such as? I can think of only one possibility that could be even close to >> efficient: maintain an IdentityHashMap somewhere under the >> hood. > > The obvious alternative is the make one of the existing words dual > purpose, either directly containing its data or containing an index to a > structure containing both the lock and the original use of the word. > That does require, in effect, a spare bit to indicate which mode the > object is in. Yeah, that could work if you can spare a bit from the non-lock stuff in the other original two words of object header. The above assumed that all the bits in the other two words were already spoken for. But if not, your suggestion fits well the phrase "thin lock" since the lock is essentially only 1 bit wide for most objects.