Re: [Sablevm-developer] Question about _svmf_exit_object_monitor()

[Prof. E. M. G. <eti...@uq...>]

Hi Archie,

You're the second person to ask me about it.  The first person was one
of the members of my evaluation committee during my
Ph.D. defense. :-)  So, as you were not there, I'll restate my answer.


> My question is: is this inflate operation strictly necessary? Won't
> these other threads properly handle inflating the lock when they wake up?

It is not *strictly* necessary, but it is highly desirable to avoid a
potential pathological case.  [Avoiding another pathological situation
(i.e. busy-wait) was the reason for adding this more complex unlocking
protocol!].

Imagine that the thin lock owner thread holds a very large number of
thin locks, and that it repeatedly acquires and releases one last
thin-lock repeatedly, e.g.:

synchronized(o1){
 synchronized(o2){
  ...
   ...
    synchronized(o10000000){
     for(i=0; i<1000000000000;i++){
      synchronized(a){
       do something short;
      } // synch
     } // loop
...

Assuming there is contention on o1, o2, ..., o10000000, when "a" is
unlocked, the VM *must* visit the list of 10000000 contending threads.
If we don't inflate o1,02,... then we must keep the list of contending
threads.  On the next iteration, when we release "a" again, we must
revisit this whole 10000000 element list (searching for threads
contending on "a").  Of course, you can start thinking about how to
maintain a more complex data structure so that you don't have to
revisit the whole list, but then you end-up with complex code in an
operation that we want to be as simple and as fast as possible, as it
is on the critical path of application execution.  Inflating the
locks, on the other hand, allows us to keep a very simple and
strait-forward implementation without having to worry about
pathological cases.

Personally, I think it would be more interesting to experiment and
study the necessity or not of having a "lock deflation" policy to
revert some fat locks to thin locks.  Mind you that deflating a fat
lock can be quite tricky to do, regardless of the policy, if you want
to avoid over-synchronization or bugs in corner cases.
     
Does this answer your question satisfactorily?

Etienne

> 
> This question has the following implications: inflating a lock can
> possibly throw an exception if we run out of memory. This is in fact
> the only failure mode of _svmf_exit_object_monitor() other than throwing
> an IllegalMonitorStateException.
> 
> For internal VM locks, we can assume that IllegalMonitorStateException
> will never be thrown unless there is a bug. So if we can also eliminate
> the call to _svmf_inflate_lock_no_exception(), then we can assume that
> _svmf_exit_object_monitor() will never return an error except in case
> of a bug. This would then make using object locks internally to the VM
> easier, because we'd never have a weird failure case to handle when unlocking.
> 
> Thanks,
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC.  
> Does your code think in ink? You could win a Tablet PC. 
> Get a free Tablet PC hat just for playing. What are you waiting for? 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/