Issue #12020 has been updated by Petr Chalupa.


As the previous comments mention we had a meeting to discus memory
model at RubyKaigi. There were about fifteen Ruby implementers siting around the
table from MRI, JRuby, JRuby+Truffle, and OMR.

The first meeting started by exchanging little bit of background information. We
then freely discussed few topics:

*   why are volatile variables needed and some examples
*   concurrency models, why is shared memory sometimes convenient and needed
*   how would be volatile variables made available in Ruby (in every object vs
    by a proxy)

The topics were useful to exchange background and to understand each other
better, however we did not reach any agreement on any of the topics. We
realised that we need some real examples to discuss.

For the next meeting Benoit had prepared code examples that better illustrate
the problems faced by language implementers without a memory model in place. In
particular, we focused on the problems that affect instance variables in shared
Ruby objects. When operations like: instance variable update, new instance
variable definition, instance variable type profile change are executed on an
object concurrently and/or in parallel the following must not happen:

*   An update of an instance variable is lost
    (see https://docs.google.com/document/d/1pVzU8w_QF44YzUCCab990Q_WZOdhpKolCIHaiXG-sPw/edit#heading=h.eukpz1zhpmm2)
*   A value out-of-thin-air is read

This helped us to reach agreement that **we need a minimal memory model** which
would forbid exactly this type of surprising behaviour. Personally I think this
is great.

The same day we had followup meeting with reduced number of attendees Koichi,
Benoit and me. We've discussed in detail the current proposed properties for
different types of variables. Koichi found them reasonable but of course he
will be evaluating it further and discussing the memory model with other MRI
developers.

The next steps are:

*   Improve the memory model document to make it more understandable (e.g. by
    adding examples)
*   Continue in the discussions around properties of the variables to determine 
    if the current proposal is fine or if it needs changes

----------------------------------------
Feature #12020: Documenting Ruby memory model
https://bugs.ruby-lang.org/issues/12020#change-60715

* Author: Petr Chalupa
* Status: Assigned
* Priority: Normal
* Assignee: Koichi Sasada
----------------------------------------
Defining a memory model for a language is necessary to be able to reason about a program behavior in a concurrent or parallel environment. 

There was a document created describing a Ruby memory model for concurrent-ruby gem, which fits several Ruby language implementations. It was necessary to be able to build lower-level unifying layer that enables creation of concurrency abstractions. They can be implemented only once against the layer, which ensures that it runs on all Ruby implementations.

The Ruby MRI implementation has stronger undocumented guaranties because of GIL semantics than the memory model, but the few relaxations from MRIs behavior allow other implementations to fit the model as well and to improve performance.

This issue proposes to document the Ruby memory model. The above mentioned memory model document which was created for concurrent-ruby can be used as a starting point: https://docs.google.com/document/d/1pVzU8w_QF44YzUCCab990Q_WZOdhpKolCIHaiXG-sPw/edit#. Please comment in the document or here.

The aggregating issue of this effort can be found [here](https://bugs.ruby-lang.org/issues/12019).



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>