Re: [Sablevm-developer] SableVM requirement for sequential consistency

[Etienne M. G. <eti...@uq...>]

Hi Professor Pugh,

> Does everyone understand that no commodity multiprocessor offers a 
> sequentially consistent memory model, and that in particular x86 and 
> Alpha SMPs are not sequentially consistent?
 >
 > In fact, the Alpha has the weakest memory model that I know of.
 >
 > What is the story?

I wrote this note, and yes I do know that no commodity multiprocessor offers a 
sequentially consistent memory model.

SableVM claims "easy portability".  In my definition, this means that you should 
only have to modify a few well identified functions and macro definitions, and 
possibly implement a few inline assembly functions, and you're done.

Now, Implementing an "efficient" JVM requires one to pay attention to the cost 
of operations, and more specifically, synchronization operations.

The only "system independent" synchronization operations available to a 
relatively pure ISO C/POSIX program are pthread operations, which can become 
very costly if used too frequently.  For such reasons, people have developed 
"light" synchronization schemes; in particular D. Bacon's thin locks[1].

A "sound" implementation of thin locks, on a multi-processor system, would have 
to flush the cache in the "non-atomic" monitor exit implementation.  (This cache 
  flush business is not discussed in his paper).  Currently, SableVM implements 
no  such system-specific operation in "_svmf_exit_object_monitor()".

SableVM implements thin locks, and a few other tricks for operations that would 
otherwize require "full synchronization" (e.g. pthread_mutex_lock()).  The 
soundness of such operations, on SMP systems, would require adding cache 
related, system-specific, inline assembly function calls.

I have quickly investigated the question, at some point, (yes, I have also taken 
graduate courses on multi-processors, covering the many weak memory model 
designs), but I quickly discovered that every processor has its own cache 
related instructions, with various definitions of "memory barriers", etc.  So, 
my supervisor and me decided that we would leave this stuff outside the scope of 
my Ph.D. .  There's only so much you can do, in a single Ph.D.; you want to 
leave a few things for tenure track too... ;-)

So, in summary, the POSIX and strong memory model requirements on the SableVM 
web page are "weak" requirements.  These requirements only imply that porting to 
systems that do not meet these requirements will require a little more work, and 
probably some discussions with the VM designer to identify all the necessary 
modification points.  I admit: I should have been clearer on this.  I will 
update the web page.  [I also wanted to anticipate bug reports about misbehavior 
  of the current SableVM implementation on a multi-processor system].

Incidentally, I had a few questions I wanted to eventually ask you on the 
subject.  I would be very grateful if you could help me with some replies, when 
I get out of my current rush and have some time to carefully write the questions 
down (in the Fall).

Regards,

Etienne

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