Re: [Cuis-dev] Write Barriers
Locked
 
|
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
-KenD
|
|
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:
|
|
|
> 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/ |
Re: [Cuis-dev] Write Barriers
|
|
Hi All, On Wed, Feb 6, 2019 at 1:00 PM Chris Muller <[hidden email]> wrote:
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
_,,,^..^,,,_ best, Eliot |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |