On 25 March 2011 19:22, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
>
>
> On Fri, Mar 25, 2011 at 7:08 PM, Toon Verwaest <toon.verwaest@gmail.com>
> wrote:
>>
>>>> What do you think?
>>>
>>> I am for... for the JIT is is a monomorphic send to a primitive, so the
>>> IC will be very effective
>>> and should take care that the lookup is actually almost never done. (and
>>> the lookup is the
>>> only thing the #class bytecode saves, as the target method is a
>>> primitive).
>>
>> I think that programmers should have the illusion that the VM interacts
>> with the system through message sends. By being able to overwrite this
>> particular message you break this illusion. The VM will just fetch the real
>> class; but the user doesn't get access to it anymore. Telling the system
>> that this particular message shouldn't be overwritten is probably a good
>> thing.
>>
>> If you want to overwrite the method class, maybe your tools should send
>> another message than class in the first place?
>
> Of course I can do that. I can also do
>
> ��� (ParseNode classVarNamed:� 'StdSelectors') removeKey: #class ifAbsent:
> [].
> ��� Compiler recompileAll.
>
> I don't care. I have it working for my "usage". This was just an example.
>
> And don't compare #class with all the boolean methods like #ifNil:� and
> friends� or the bytecodes for integer operations....I think #class is sent
> far less times than those...
>

Yes. and i predict that performance impact in macro benchmarks, where
you running normal code
(which not sending this message intentionally in a loop) will be at
the noise level magnitude.

>
>>
>> I do however agree that many other optimizations become slightly
>> superfluous, such as bytecodes for integer operations ... that somehow seems
>> like compile-time inline-cached behavior without the ability to flush the
>> cache :)
>>
>> cheers,
>> Toon
>>
>
>

--
Best regards,
Igor Stasenko AKA sig.