2013/11/26 Max Leske <maxleske@gmail.com>

Thanks for the explanation. I suspected something like that (interestingly when I tried disabling all options on my Mac it worked fine�).

This is because you didn't execute: 'OpalCompiler recompileAll'.�

I�ll dig some more and let you know.

We should dig into the '3 timesRepeat: [ Smalltalk garbageCollect ]', because this may be a bug somewhere. Now we shouldn't dig into having a system running without condition and loops inlined by the compiler, because this is too much work (for example as Marcus said loops on all objects should not create an object (even a context) ...). If we really want that we will invest time. But right now it is not a priority.

On 25.11.2013, at 18:42, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Mon, Nov 25, 2013 at 9:37 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 25 Nov 2013, at 17:56, Cl�ment Bera <bera.clement@gmail.com> wrote:

> Yeah you cannot compile without inlining specific messages. You can disable inlining of #timesRepeat: at image level because we added it for fun to see if it was easy to do in Opal. Now all other optimizations were in the old compiler and are mandatories. However, you can now in Opal disable these optimized messages in a restricted area (such as a class and its subclasses).
>
> To me, it is kind of a bug that we cannot disable those optimizations, we should be able to do it (so 1 day in the very very far future we could have the JIT inlining these control structure allowing us to implement all these inlined messages in all classes). But one thing is that some methods such as #whileTrue are not implemented in a way they really work (they have not stop condition, so if the compiler does not inline it, it gives you an infinite loop). Another thing is the interrupt point problem as Marcus said.
>
> I don't think your other bug is related Opal optimization, only #timesRepeat: is new and therefore can be faulty (and in this case, the bytecode is correct, so I guess it is faulty because it removes an interrupt point).

It is a bit scary that there is no explicit, crystal clear list of those interrupt critical points, especially if skipping them can lead to VM crashes.

Before we raise the alarm the first thing is to identify the cause of the VM crash. �It could still be a VM bug. �First track down the bug. �Don't try and find work-arounds. �Try and find the cause. �Only then can one develop a correct fix. �Anything else buries the true cause under hacks, a process that is truly scary ;-)

�

> 2013/11/25 Marcus Denker <marcus.denker@inria.fr>
>
> On 25 Nov 2013, at 16:26, Max Leske <maxleske@gmail.com> wrote:
>
> > Thanks Cl�ment, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like there�s another (Opal related?) problem (with the exact same symptoms�).
> >
> > I�ve tried disabling all options, just to see what happens: all builds fail with SegFaults�
>
> You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now
> And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problem�
>
> � � � � Marcus
>

--
best,
Eliot