Current Status

Thu Feb 18 13:40:00 GMT 1999

On 1999年2月18日, Godmar Back wrote:
>>While a thread owns the monitor, the hashcode is evicted and a pointer to
>a slot on your own stack is written where the hashcode normally sits.
>Hence, you can figure out whether you own the lock already by checking
>that this pointer points to a location further up on your stack if you
>encounter a locked object.
>>See http://www.mozilla.org/projects/ef/techdocs/design/monitors_32.html
>for a nice and detailed explanation.
>>	- Godmar

Very interesting. Means that heavy monitors get allocated only for synchronized
objects that are currently contended. One possible disadvantage is that
allocating these heavy monitors and storing them in a hash table is a
potentially costly operation. Since the heavy monitors are instantiated on
a per-thread/per-object basis, then discarded when the monitor is acquired,
applications which routinely contend for objects would suffer.
--
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790