Jitted methods cache primitive failures?
Locked
Jitted methods cache primitive failures?
 
|
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. 6. Evaluate [SqueakSSL compileAll] and then [SqueakSSL new]. This time it should work. Levente |
Re: Jitted methods cache primitive failures?
|
|
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. 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 |
Re: Jitted methods cache primitive failures?
|
|
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. Without knowing this, people will spend hours trying to find out why their plugin won't work. 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 > > |
Re: Jitted methods cache primitive failures?
|
|
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 > > > > |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |