[Vm-dev] Jitted methods cache primitive failures?

[David T. Lewis]

On Mon, May 02, 2016 at 01:38:59AM +0200, Levente Uzonyi wrote:
> 
> Hi Dave,
> 
> On Sun, 1 May 2016, David T. Lewis wrote:
> 
> >
> >On Mon, May 02, 2016 at 12:44:58AM +0200, Levente Uzonyi wrote:
> >>
> >>Hi All,
> >>
> >>If you try to use a method with a primitive, and that primitive fails for
> >>the first time for some reason (e.g. the plugin can't be loaded), then
> >>subsequent sends of the same method will always fail, even if they would
> >>work normally. The workaround I found was recompiling the method.
> >>To reproduce:
> >>1. Open a Squeak Trunk image with a working SqueakSSL plugin.
> >>2. Rename the plugin to SqueakSSL_.
> >>3. Evaluate [SqueakSSL new]. Its primitive should fail.
> >>4. Close the debugger and rename the plugin to SqueakSSL.
> >>5. Try [SqueakSSL new] again. It's primitive should fail again, despite
> >>the fact that the plugin is at its place.
> >
> >This is a good thing. If the VM cannot load the plugin the first time it 
> >tries,
> >then it should not try again. Loading the plugin on first reference is 
> >fairly
> >expensive, so you would not want to try it again every time you call the
> >primitive. It works this way on the interpreter VM too.
> 
> If this is really intentional, then users should be warned about this. 

I don't know how to warn users, but check method category "modules" in
SmalltalkImage. There is #forgetModule: which will tell the VM to try loading
a module the next time one of its primitives is referenced, as well as
#unbindExternalPrimitives which should clear out all of the previously
cached primitive references.


> Without knowing this, people will spend hours trying to find out why their 
> plugin won't work.

I know that feeling ;-)

Dave

> In case of SqueakSSL this is pretty bad, because the plugin shipped with 
> the official VMs don't work on debian based systems.
> 
> Levente
> 
> >
> >However, if a primitive fails for some other reason, such as failing a 
> >parameter
> >check, that failure should not affect the next call to the primitive. If 
> >that
> >is what is happening, then maybe we have a bug.
> >
> >>6. Evaluate [SqueakSSL compileAll] and then [SqueakSSL new]. This time it
> >>should work.
> >>
> >
> >I did not check, but this may be part of the existing mechanism.
> >
> >Dave
> >
> >