[Pharo-dev] Tuning Opal Optimizations

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Nov 21 13:59:37 EST 2013


I fail to see what atomic means in this context, it's too broad idea.
To me atomic would be: compile all in a certain sequence, then install all
at once atomically.
And in this case, there is still a problem, because it would resolve
installation order, not compilation order...

The idea of compiling class side first sounds good to me.
It's not atomic, but might just work.


2013/11/21 Marcus Denker <marcus.denker at inria.fr>

>
> 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/b7218b40/attachment-0002.html>


More information about the Pharo-dev mailing list