Re: [Cuis-dev] Write Barriers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Cuis-dev] Write Barriers

ken.dickey
 
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
Reply | Threaded
Open this post in threaded view
|

Re: [Cuis-dev] Write Barriers

Clément Béra
 
Hi,

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 very cheaply performance-wise, and write image-level code to deal with the mutation.

Best,

On Tue, Feb 5, 2019 at 1:31 AM <[hidden email]> 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


--
Reply | Threaded
Open this post in threaded view
|

Re: [Cuis-dev] Write Barriers

Chris Muller-3
 
> 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.


 - 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 <[hidden email]> 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/
Reply | Threaded
Open this post in threaded view
|

Re: [Cuis-dev] Write Barriers

Eliot Miranda-2
 
Hi All,

On Wed, Feb 6, 2019 at 1:00 PM Chris Muller <[hidden email]> 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, etc.

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
HTH



 - 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 <[hidden email]> 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