[Vm-dev] [Cuis-dev] Write Barriers

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 6 23:50:31 UTC 2019

Hi All,

On Wed, Feb 6, 2019 at 1:00 PM Chris Muller <asqueaker at gmail.com> wrote:

> > The write barrier was introduced in the VM a few years ago and is
> available at image level through a few extra primitives and the rewrite of
> the fall-back code of primitives mutating objects. VM support is complete.
> >
> > The typical thing implemented on top of the write barrier is to detect
> the next time an object is mutated
> That is easier said than done.  How could this be accomplished
> transparently?  Geralds question is:
> >> > Alas, I just discovered, that I have to modify a lot of
> >> > #at:put:-primitives to make it work with Array and similar
> >> > classes.
> Ideally, a single Exception handler would be able to handle all cases,
> but it appears they have to be sprinkled about everywhere, including
> in base code.  Worse, if one is missed, it'll simply be a silent bug
> in the system, which is untenable.

There is a design that works in VisualWorks; it is based on exactly
analogous machinery that Clément wrote for OpenSmalltalk.  The idea is not
so much to have a single exception handler as have a single execution class
and have its defaultAction provide the hooks one wants for system-wide
handling of the write-barrier.

So the idea is to modify all mutating primitive methods (at the Smalltalk
level) so that they look for the right error code (#'no modification') and
raise the relevant exception (NoModificationError matches VW, but not
Pharo) via sending noModificationErrorFor:index:value:.
NoModificationError then maintains a (weak) set of objects for which one
wants to handle the write-barrier, in the form of an object to a action
map, so that various clients can install specific actions for particular
objects.  The exception's defaultAction then looks up the receiver in the
map and performs the action if it is there, otherwise raising a notifier.
Specific clients can catch the exception if they want, but should ion most
cases allow the defaultAction to do the job of selecting the right action
for the right object, since this is not usually context-dependent, but
receiver-dependent.  For example, an object that is a literal should always
raise a "no modification" error, an object that is part of an
object-database mapping system should be written through to the database,

Now what I've written above is only a design sketch, an d corresponds to my
memory of what the VW system did that was implemented primarily to work
with GemStone.  Martin McClure will have something relevant to contribute
here.  What I would suggest to the Squeak community its that we look
carefully at what the Pharo community has done.  There was some discussion
last year (IIRC) driven by Denis Kudriashov in suggesting a better name for
the exception, etc, and there may have been some work with the GemStone
team on a prototype implementation. AFAIA all the standard Spur VMs include
the write barrier since March 17th of 2018.

Denis, Clément, what its the state of Pharo use of the write barrier?

cheers, Eliot

>  - Chris
> > very cheaply performance-wise, and write image-level code to deal with
> the mutation.
> >
> > Best,
> >
> > On Tue, Feb 5, 2019 at 1:31 AM <ken.dickey at whidbey.com> wrote:
> >>
> >>
> >> On 2019-02-04 13:26, Gerald Klix via Cuis-dev wrote:
> >> ..
> >> > I am implementing a package that supports the write barriers
> >> > implemented in the current virtual machine.
> >> > The package was meant to be an add-on to Cuis-Standard-Image.
> >> > Alas, I just discovered, that I have to modify a lot of
> >> > #at:put:-primitives to make it work with Array and similar
> >> > classes. Therefore I would like have this package integrated
> >> > in with current image, once it is finished.
> >>
> >> Gerald,
> >>
> >> As a long time advocate of "the simplest thing that will work", I am
> >> wondering at what your goal and purpose is here.  What cool things are
> >> you doing/adding that require a write barrier?
> >>
> >> Perhaps you should be looking at VMMaker and doing things at the VM
> >> level?  If so, you might make a case in the vm-dev mailing list for
> >> direct support.
> >>
> >> $0.02,
> >> -KenD
> >
> >
> >
> > --
> > Clément Béra
> > https://clementbera.github.io/
> > https://clementbera.wordpress.com/

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190206/c4a98c8c/attachment.html>

More information about the Vm-dev mailing list