[Pharo-dev] Tuning Opal Optimizations

Marcus Denker marcus.denker at inria.fr
Thu Nov 21 10:15:23 EST 2013


On 21 Nov 2013, at 15:55, Igor Stasenko <siguctua at gmail.com> wrote:

> 
> 
> 
> On 21 November 2013 12:30, Marcus Denker <marcus.denker at inria.fr> wrote:
> 
> On 21 Nov 2013, at 11:34, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> 
> >
> > On 19 Nov 2013, at 16:45, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> >
> >>>
> >>> Yes, you can do it per class-hierarchy… you can implement on the class side a method to parametrize the compiler:
> >>>
> >>> compiler
> >>>     ^super compiler options: #(- optionInlineTimesRepeat)
> >>
> >> Thanks, Marcus, that works just great.
> >
> > Marcus,
> >
> > Are we sure this option mechanism works when loading code through Monticello ?
> >
> 
> No… we should make sure that MC loads the method first. I think it does that for #compilerClass
> already (but not sure).
> 
> 
> which is still doesn't eliminates problem completely, because nothing prevents me from having:
> 
> compilerClass
>   ^ self otherMethod
> 
> and now in order to work,  MC have to know somehow that #otherMethod should also be loaded first.
> But i think some prioritization guarantees would be really useful.
> At least i think we can easily prioritize class-side compilation over instance side. 
> Like that, when you compiling any of instance-side method, you know that class side is already there (and can be used
> as such in different kinds of hooks).
> 
>  

yes, we need atomic code loading.

	Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131121/e5afa73b/attachment-0002.html>


More information about the Pharo-dev mailing list