NewCompiler load on PharoCore

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

NewCompiler load on PharoCore

Miguel Cobá
Hi Markus,

what is the correct way to load NewCompiler in a PharoCore image.

I am loading with:

Gofer it
  squeaksource: 'NewCompiler';
  package: 'NewCompiler';
  load.

But it has dependencies on SmaCCParserError.

Then looking at the

NewCompilerLoader >> loadPackages

loadPackages

        self loadLatestPackage: 'AST-Core' from: 'http://www.squeaksource.com/rb/'.
" self loadLatestPackage: 'SmaCC-' from: 'http://www.squeaksource.com/SmaccDevelopment/'.
        self loadLatestPackage: 'NewParser-' from: 'http://www.squeaksource.com/AST/'."
        self loadLatestPackage: 'NewCompiler-' from: 'http://www.squeaksource.com/NewCompiler/'.
       
        "Preferences setPreference: #compileUseNewCompiler toValue: true.
        Compiler recompileAll." "no, not working yet"

so this are all the dependencies?

Has NewCompiler teste on PharoCore?

Is there a gofer script to load it? Or better a Metacello configuration?

If you can give me the dependencies I can create the Metacello
configuration. Right now I am creating the configurations for Magma and
through WriteBarrier, they depend on NewCompiler.

Thanks

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Lukas Renggli
> Has NewCompiler teste on PharoCore?

Jorge is working on it. It does not work on Pharo yet.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Miguel Cobá
El mar, 12-01-2010 a las 19:36 +0100, Lukas Renggli escribió:
> > Has NewCompiler teste on PharoCore?
>
> Jorge is working on it. It does not work on Pharo yet.

Ok, thanks, for the moment will omit the WriteBarrier on NewCompiler in
the Metacello configuration for Magma.

Thanks


>
> Lukas
>

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Mariano Martinez Peck
Magma depends on NewCompiler ??? weird.....is NewCompiler working in squeak ?

2010/1/12 Miguel Enrique Cobá Martinez <[hidden email]>
El mar, 12-01-2010 a las 19:36 +0100, Lukas Renggli escribió:
> > Has NewCompiler teste on PharoCore?
>
> Jorge is working on it. It does not work on Pharo yet.

Ok, thanks, for the moment will omit the WriteBarrier on NewCompiler in
the Metacello configuration for Magma.

Thanks


>
> Lukas
>

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Lukas Renggli
> Magma depends on NewCompiler ??? weird.....is NewCompiler working in squeak

No, the new closures broke it. It had its own (slow) closure implementation.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Miguel Cobá
In reply to this post by Mariano Martinez Peck
El mar, 12-01-2010 a las 17:20 -0300, Mariano Martinez Peck escribió:
> Magma depends on NewCompiler ??? weird.....is NewCompiler working in
> squeak ?

Weird ins't? But yes, indirectly. Magma loads WriteBarrier and
WriteBarrier uses BytecodeGenerator that is part of NewCompiler.

I asked Chris Muller about this dependency but until a proper fix
(either in Magma or in NewCompiler) I am loading WriteBarrier without
loading NewCompiler. :)

Cheers

>
> 2010/1/12 Miguel Enrique Cobá Martinez <[hidden email]>
>         El mar, 12-01-2010 a las 19:36 +0100, Lukas Renggli escribió:
>         > > Has NewCompiler teste on PharoCore?
>         >
>         > Jorge is working on it. It does not work on Pharo yet.
>        
>        
>         Ok, thanks, for the moment will omit the WriteBarrier on
>         NewCompiler in
>         the Metacello configuration for Magma.
>        
>         Thanks
>        
>        
>         >
>         > Lukas
>         >
>        
>         --
>         Miguel Cobá
>         http://miguel.leugim.com.mx
>        
>        
>         _______________________________________________
>        
>        
>         Pharo-project mailing list
>         [hidden email]
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Chris Muller-3
In reply to this post by Mariano Martinez Peck
2010/1/12 Mariano Martinez Peck <[hidden email]>:
> Magma depends on NewCompiler ???

No, WriteBarrier depends on NewCompiler.

Magma can, at the explicit option of the user, turn on the
WriteBarrier option if the WriteBarrier package is present.
WriteBarrier used to be self-contained, later it became dependent on
NewCompiler.

Unless the WriteBarrier option is switched on by the user, its
presence or absence in the image (as well as NewCompiler) has no
effect on Magma.

 - Chris

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Mariano Martinez Peck


On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
2010/1/12 Mariano Martinez Peck <[hidden email]>:
> Magma depends on NewCompiler ???

No, WriteBarrier depends on NewCompiler.

Magma can, at the explicit option of the user, turn on the
WriteBarrier option if the WriteBarrier package is present.
WriteBarrier used to be self-contained, later it became dependent on
NewCompiler.

Unless the WriteBarrier option is switched on by the user, its
presence or absence in the image (as well as NewCompiler) has no
effect on Magma.


Thanks for the clarification Chris. It was strange for me that  as I used Magma a couple of times and I never installed WriteBarrier neither NewCompiler.

Cheers

Mariano

 
 - Chris

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Igor Stasenko
Can someone clarify, why WriteBarrier depends on compiler (new
compiler or old compiler - not really important).
I just wonder what compiler functionality its depends on.

2010/1/13 Mariano Martinez Peck <[hidden email]>:

>
>
> On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
>>
>> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> > Magma depends on NewCompiler ???
>>
>> No, WriteBarrier depends on NewCompiler.
>>
>> Magma can, at the explicit option of the user, turn on the
>> WriteBarrier option if the WriteBarrier package is present.
>> WriteBarrier used to be self-contained, later it became dependent on
>> NewCompiler.
>>
>> Unless the WriteBarrier option is switched on by the user, its
>> presence or absence in the image (as well as NewCompiler) has no
>> effect on Magma.
>>
>
> Thanks for the clarification Chris. It was strange for me that  as I used
> Magma a couple of times and I never installed WriteBarrier neither
> NewCompiler.
>
> Cheers
>
> Mariano
>
>
>>
>>  - Chris
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Lukas Renggli
> Can someone clarify, why WriteBarrier depends on compiler (new
> compiler or old compiler - not really important).
> I just wonder what compiler functionality its depends on.

WriteBarrier introduces something like immutable objects at the
language level by rewriting all state access in an anonymous subclass.
Having a compiler at hand certainly makes things simpler.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Miguel Cobá
In reply to this post by Igor Stasenko
El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió:
> Can someone clarify, why WriteBarrier depends on compiler (new
> compiler or old compiler - not really important).
> I just wonder what compiler functionality its depends on.

WriteBarrier uses the class BytecodeGenerator that is part of the
package NewCompiler (that is currently on rewrite for the closure
images). Why it need it and how it use it, I really don't know. I have
only a vague idea of what WriteBarrier does, and as Mariano said, I use
Magma but never used or activated the WriteBarrier functionality of it.

Cheers

>
> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
> >
> >
> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
> >>
> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
> >> > Magma depends on NewCompiler ???
> >>
> >> No, WriteBarrier depends on NewCompiler.
> >>
> >> Magma can, at the explicit option of the user, turn on the
> >> WriteBarrier option if the WriteBarrier package is present.
> >> WriteBarrier used to be self-contained, later it became dependent on
> >> NewCompiler.
> >>
> >> Unless the WriteBarrier option is switched on by the user, its
> >> presence or absence in the image (as well as NewCompiler) has no
> >> effect on Magma.
> >>
> >
> > Thanks for the clarification Chris. It was strange for me that  as I used
> > Magma a couple of times and I never installed WriteBarrier neither
> > NewCompiler.
> >
> > Cheers
> >
> > Mariano
> >
> >
> >>
> >>  - Chris
> >>
> >> _______________________________________________
> >> Pharo-project mailing list
> >> [hidden email]
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Igor Stasenko
In reply to this post by Lukas Renggli
2010/1/13 Lukas Renggli <[hidden email]>:
>> Can someone clarify, why WriteBarrier depends on compiler (new
>> compiler or old compiler - not really important).
>> I just wonder what compiler functionality its depends on.
>
> WriteBarrier introduces something like immutable objects at the
> language level by rewriting all state access in an anonymous subclass.
> Having a compiler at hand certainly makes things simpler.
>
Hmm.. what about primitives , which mutating the state of receiver?
Even worse, there are some, which mutating the state of argument(s).

> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Gary Chambers-4
----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 13, 2010 4:56 PM
Subject: Re: [Pharo-project] NewCompiler load on PharoCore


> 2010/1/13 Lukas Renggli <[hidden email]>:
>>> Can someone clarify, why WriteBarrier depends on compiler (new
>>> compiler or old compiler - not really important).
>>> I just wonder what compiler functionality its depends on.
>>
>> WriteBarrier introduces something like immutable objects at the
>> language level by rewriting all state access in an anonymous subclass.
>> Having a compiler at hand certainly makes things simpler.
>>
> Hmm.. what about primitives , which mutating the state of receiver?
> Even worse, there are some, which mutating the state of argument(s).

Indeed, perhaps the push/pop remappableOop could factor the write barrier
in...

>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Lukas Renggli
>>> WriteBarrier introduces something like immutable objects at the
>>> language level by rewriting all state access in an anonymous subclass.
>>> Having a compiler at hand certainly makes things simpler.
>>>
>> Hmm.. what about primitives , which mutating the state of receiver?
>> Even worse, there are some, which mutating the state of argument(s).

I don't know how WriteBarrier solves that problem (and if it really
matters in this case), but it can be:
http://scg.unibe.ch/archive/papers/Reng08aTransMemory.pdf

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Chris Muller-3
In reply to this post by Miguel Cobá
A great description of what WriteBarrier does and how it works can be
found in the WriteBarrier class-comment, itself.

In a nutshell, when an object is added to a WriteBarrier, a subclass
is dynamically compiled for it, but not added to the Smalltalk
dictionary.  The name of the class is the same as its superclass but
with a '*' appended to it.

After creating the subclass, WriteBarrier looks at all "definitions"
of each instance variable, and adds methods to override the methods in
its superclass.  The generated override checks the pre-state of the
instVar, calls super, then compares the post-state of the instVar to
the pre-state.

If it changed, it signals so that the application (Magma) can mark it dirty.

So, it allows Magma to operate with a smaller readSet, which speeds up
the part of the commit process relating to detection of changed
objects for building the CommitPackage which is shipped off to the
server..

 - Chris

2010/1/13 Miguel Enrique Cobá Martinez <[hidden email]>:

> El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió:
>> Can someone clarify, why WriteBarrier depends on compiler (new
>> compiler or old compiler - not really important).
>> I just wonder what compiler functionality its depends on.
>
> WriteBarrier uses the class BytecodeGenerator that is part of the
> package NewCompiler (that is currently on rewrite for the closure
> images). Why it need it and how it use it, I really don't know. I have
> only a vague idea of what WriteBarrier does, and as Mariano said, I use
> Magma but never used or activated the WriteBarrier functionality of it.
>
> Cheers
>>
>> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
>> >
>> >
>> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
>> >>
>> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> >> > Magma depends on NewCompiler ???
>> >>
>> >> No, WriteBarrier depends on NewCompiler.
>> >>
>> >> Magma can, at the explicit option of the user, turn on the
>> >> WriteBarrier option if the WriteBarrier package is present.
>> >> WriteBarrier used to be self-contained, later it became dependent on
>> >> NewCompiler.
>> >>
>> >> Unless the WriteBarrier option is switched on by the user, its
>> >> presence or absence in the image (as well as NewCompiler) has no
>> >> effect on Magma.
>> >>
>> >
>> > Thanks for the clarification Chris. It was strange for me that  as I used
>> > Magma a couple of times and I never installed WriteBarrier neither
>> > NewCompiler.
>> >
>> > Cheers
>> >
>> > Mariano
>> >
>> >
>> >>
>> >>  - Chris
>> >>
>> >> _______________________________________________
>> >> Pharo-project mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Eliot Miranda-2
A *much* better way to implement this is to support immutability in the VM (I know, I know, but all the code is available in the Newspeak VM), mark objects one wants to mark as dirty as immutable, catch the NoModificationError exception, and proceed after having made the object mutable and marked it dirty.  No creating hidden classes, no trying to get change class to work for compact classes, etc.  Just a simple VM-implemented write barrier that can also be used for a host of other things (object-database mapping, debugging, immutable literals etc).

On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <[hidden email]> wrote:
A great description of what WriteBarrier does and how it works can be
found in the WriteBarrier class-comment, itself.

In a nutshell, when an object is added to a WriteBarrier, a subclass
is dynamically compiled for it, but not added to the Smalltalk
dictionary.  The name of the class is the same as its superclass but
with a '*' appended to it.

After creating the subclass, WriteBarrier looks at all "definitions"
of each instance variable, and adds methods to override the methods in
its superclass.  The generated override checks the pre-state of the
instVar, calls super, then compares the post-state of the instVar to
the pre-state.

If it changed, it signals so that the application (Magma) can mark it dirty.

So, it allows Magma to operate with a smaller readSet, which speeds up
the part of the commit process relating to detection of changed
objects for building the CommitPackage which is shipped off to the
server..

 - Chris

2010/1/13 Miguel Enrique Cobá Martinez <[hidden email]>:
> El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió:
>> Can someone clarify, why WriteBarrier depends on compiler (new
>> compiler or old compiler - not really important).
>> I just wonder what compiler functionality its depends on.
>
> WriteBarrier uses the class BytecodeGenerator that is part of the
> package NewCompiler (that is currently on rewrite for the closure
> images). Why it need it and how it use it, I really don't know. I have
> only a vague idea of what WriteBarrier does, and as Mariano said, I use
> Magma but never used or activated the WriteBarrier functionality of it.
>
> Cheers
>>
>> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
>> >
>> >
>> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]> wrote:
>> >>
>> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> >> > Magma depends on NewCompiler ???
>> >>
>> >> No, WriteBarrier depends on NewCompiler.
>> >>
>> >> Magma can, at the explicit option of the user, turn on the
>> >> WriteBarrier option if the WriteBarrier package is present.
>> >> WriteBarrier used to be self-contained, later it became dependent on
>> >> NewCompiler.
>> >>
>> >> Unless the WriteBarrier option is switched on by the user, its
>> >> presence or absence in the image (as well as NewCompiler) has no
>> >> effect on Magma.
>> >>
>> >
>> > Thanks for the clarification Chris. It was strange for me that  as I used
>> > Magma a couple of times and I never installed WriteBarrier neither
>> > NewCompiler.
>> >
>> > Cheers
>> >
>> > Mariano
>> >
>> >
>> >>
>> >>  - Chris
>> >>
>> >> _______________________________________________
>> >> Pharo-project mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Chris Muller-3
Sounds great, I agree that is cleaner than the old WriteBarrier hack.
Of course, I'd also like look into using a JIT-compiler enabled VM
that can make *everything* a bit faster, not just Magma commits..

2010/1/13 Eliot Miranda <[hidden email]>:

> A *much* better way to implement this is to support immutability in the VM
> (I know, I know, but all the code is available in the Newspeak VM), mark
> objects one wants to mark as dirty as immutable, catch the
> NoModificationError exception, and proceed after having made the object
> mutable and marked it dirty.  No creating hidden classes, no trying to get
> change class to work for compact classes, etc.  Just a simple VM-implemented
> write barrier that can also be used for a host of other things
> (object-database mapping, debugging, immutable literals etc).
>
> On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <[hidden email]> wrote:
>>
>> A great description of what WriteBarrier does and how it works can be
>> found in the WriteBarrier class-comment, itself.
>>
>> In a nutshell, when an object is added to a WriteBarrier, a subclass
>> is dynamically compiled for it, but not added to the Smalltalk
>> dictionary.  The name of the class is the same as its superclass but
>> with a '*' appended to it.
>>
>> After creating the subclass, WriteBarrier looks at all "definitions"
>> of each instance variable, and adds methods to override the methods in
>> its superclass.  The generated override checks the pre-state of the
>> instVar, calls super, then compares the post-state of the instVar to
>> the pre-state.
>>
>> If it changed, it signals so that the application (Magma) can mark it
>> dirty.
>>
>> So, it allows Magma to operate with a smaller readSet, which speeds up
>> the part of the commit process relating to detection of changed
>> objects for building the CommitPackage which is shipped off to the
>> server..
>>
>>  - Chris
>>
>> 2010/1/13 Miguel Enrique Cobá Martinez <[hidden email]>:
>> > El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió:
>> >> Can someone clarify, why WriteBarrier depends on compiler (new
>> >> compiler or old compiler - not really important).
>> >> I just wonder what compiler functionality its depends on.
>> >
>> > WriteBarrier uses the class BytecodeGenerator that is part of the
>> > package NewCompiler (that is currently on rewrite for the closure
>> > images). Why it need it and how it use it, I really don't know. I have
>> > only a vague idea of what WriteBarrier does, and as Mariano said, I use
>> > Magma but never used or activated the WriteBarrier functionality of it.
>> >
>> > Cheers
>> >>
>> >> 2010/1/13 Mariano Martinez Peck <[hidden email]>:
>> >> >
>> >> >
>> >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> 2010/1/12 Mariano Martinez Peck <[hidden email]>:
>> >> >> > Magma depends on NewCompiler ???
>> >> >>
>> >> >> No, WriteBarrier depends on NewCompiler.
>> >> >>
>> >> >> Magma can, at the explicit option of the user, turn on the
>> >> >> WriteBarrier option if the WriteBarrier package is present.
>> >> >> WriteBarrier used to be self-contained, later it became dependent on
>> >> >> NewCompiler.
>> >> >>
>> >> >> Unless the WriteBarrier option is switched on by the user, its
>> >> >> presence or absence in the image (as well as NewCompiler) has no
>> >> >> effect on Magma.
>> >> >>
>> >> >
>> >> > Thanks for the clarification Chris. It was strange for me that  as I
>> >> > used
>> >> > Magma a couple of times and I never installed WriteBarrier neither
>> >> > NewCompiler.
>> >> >
>> >> > Cheers
>> >> >
>> >> > Mariano
>> >> >
>> >> >
>> >> >>
>> >> >>  - Chris
>> >> >>
>> >> >> _______________________________________________
>> >> >> Pharo-project mailing list
>> >> >> [hidden email]
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-project mailing list
>> >> > [hidden email]
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Igor Stasenko AKA sig.
>> >>
>> >> _______________________________________________
>> >> Pharo-project mailing list
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> > --
>> > Miguel Cobá
>> > http://miguel.leugim.com.mx
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Martin McClure-2
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:
> A *much* better way to implement this is to support immutability in the
> VM (I know, I know, but all the code is available in the Newspeak VM),
> mark objects one wants to mark as dirty as immutable, catch the
> NoModificationError exception, and proceed after having made the object
> mutable and marked it dirty.  No creating hidden classes, no trying to
> get change class to work for compact classes, etc.  Just a simple
> VM-implemented write barrier that can also be used for a host of other
> things (object-database mapping, debugging, immutable literals etc).

Since object dirtying is at the core of the product I work with, and
I've worked extensively with both methods of implementing write barriers...

I very strongly agree with Eliot. *So* much nicer a way to do this.

Regards,

-Martin


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Igor Stasenko
2010/1/13 Martin McClure <[hidden email]>:

> Eliot Miranda wrote:
>> A *much* better way to implement this is to support immutability in the
>> VM (I know, I know, but all the code is available in the Newspeak VM),
>> mark objects one wants to mark as dirty as immutable, catch the
>> NoModificationError exception, and proceed after having made the object
>> mutable and marked it dirty.  No creating hidden classes, no trying to
>> get change class to work for compact classes, etc.  Just a simple
>> VM-implemented write barrier that can also be used for a host of other
>> things (object-database mapping, debugging, immutable literals etc).
>
> Since object dirtying is at the core of the product I work with, and
> I've worked extensively with both methods of implementing write barriers...
>
> I very strongly agree with Eliot. *So* much nicer a way to do this.
>

It could be more efficient, in respect that you don't need to create
shadow classes.
But triggering exception leads to stack unwinding to find a handler,
which inevitably leads to deoptimizing all contexts.. and if stack depth is high
(between point of writing attempt and hook, where magma will handle
exception), this will be much slower
than WriteBarrier implementation, described by Cris,
which checking the value in-place, without the need of touching
exception machinery.

Just 2 cents.

> Regards,
>
> -Martin
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: NewCompiler load on PharoCore

Marcus Denker-4
In reply to this post by Lukas Renggli

On Jan 13, 2010, at 5:11 PM, Lukas Renggli wrote:

>> Can someone clarify, why WriteBarrier depends on compiler (new
>> compiler or old compiler - not really important).
>> I just wonder what compiler functionality its depends on.
>
> WriteBarrier introduces something like immutable objects at the
> language level by rewriting all state access in an anonymous subclass.
> Having a compiler at hand certainly makes things simpler.

And modifying bytecode gets even more simpler with ByteSurgeon:

        http://scg.unibe.ch/research/bytesurgeon

... soon in a new release, closure enabled, using a DSL implemented with
Lukas' Helvetia: http://scg.unibe.ch/research/helvetia

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12