On Thu, 27 Jun 2013, Marcus Denker wrote:
On Jun 27, 2013, at 5:17 PM, Levente Uzonyi <[email protected]> wrote:
On Thu, 27 Jun 2013, Marcus Denker wrote:
On Jun 27, 2013, at 8:16 AM, Clément Bera <[email protected]> wrote:
In Pharo 3 we will support conditional optimized messages ( #ifTrue:,
#ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean
receiver. However, this feature will be slow, so one should not use it too much
(as #become:, #isKindOf:, ...). Basically Opal compiles on the fly without
optimizing it the conditional messageNode as a DoIt, run it, and jump in the
context to the pc corresponding to the next ast node. We don't generate extra
bytecode as you suggested, because it will grow the size of the image a lot and
slow down the system with extra conditions.
It's actually not a lot of code. We need to debug/fix it for all the cases,
though, this might add some more complexity:
So Opal generates the same code as the old compiler. It's just a different
implementation of #mustBeBoolean, what makes the difference.
IIUC whenever the receiver of the optimized conditional message is not true or
false, the code is decompiled, then a new CompiledMethod is created without the
optimization, it's injected onto the stack, and the execution is continued from
before where the jumpTrue: or jumpFalse: was in the original method.
As Clément wrote, this is rather slow. Maybe even too slow to be useful. A
possible improvement would be to permanently replace the original compiled
method with the deoptimized one, since the receiver is likely to be not one of
the unique Boolean instances during futher executions of the method. This way
the decompilation has to be done only once.
Though these kind of code mutations behind the scene can cause some headache
for someone who's trying to optimize the code.
The question is if it makes sense to invest in these things on top of the
current infrastructure.
Not really, but it seems like you've already started implementing it.
Levente
Marcus
