Current Status

Jon Olson olson@mmsi.com
Thu Feb 18 13:40:00 GMT 1999


On Thu, 18 Feb 1999, 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


More information about the Java mailing list