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/
|
