[VM][Linux][Experimental] betterModuleHandling: splitted in two changesets

Raab, Andreas Andreas.Raab at disney.com
Tue Feb 15 04:05:36 UTC 2000


Stephan,

[Module caching]
> It is correct that it was nice to see the missing modules in 
> ST. But on the other hand this kind of caching (by a growing 
> array) is
> - slower and
> - more complicated.

Ah, but only on first primitive invokation. There is no big difference to
your implementation now since you will call ioLoadXYZ when a function is
invoked with a new session ID (and thus the time spent to check the missing
module cache isn't even worth mentioning).

> Especially there is a problem if there are many missing 
> modules (because the searched list of module names becomes 
> longer and longer). With the current implementation it is 
> really fast!

What's long?! Ten entries?! A hundred?! Have you actually measured how long
it takes to check for missing modules?! ;-)

[Reloading modules]
> I have to apologize that I have forgotten to remove the comments
[...]
> So it is possible to attempt reloading a module if that hasn't been
> found before by evaluating Smalltalk setNewSessionID

You're right. I missed that point.

[Session ID]
> I was not sure what is the best way to do these things.

Neither am I ;-) The one thing I am relatively sure about is setting the
session ID from the unload primitive since there is quite a bit of work
going on before the new session ID is really installed (try 'MessageTally
tallySends:[Smalltalk setNewSessionID]' to see how much is going on here)
and if any process switch occurs you are in a very bad spot.

> > * There is the possible danger of a collision between the 
> > old and the new session ID.
> 
> I don't think so: In the *old* implementation there it was possible to
> incidentally reuse a session id of an earlier session (see old
> implementation of Interpreter>>primitiveExternalCall).
> According the *new* implementation the sessionID will be 
> incremented at every resuming of Squeak modulo from '1' to 
> 'SmallInteger maxVal': this should be enough for a while, also 
> with extensively reloading of modules.

I guess both versions are okay for any practical purpose. You should keep in
mind though that the old version is basically random which means that you
have a random chance of 1 in 2^58 whereas now you you can exactly predict
when things start becoming problematic (2^29 new sessions between calling
the same primitive).

> BTW: What happens with stderr at other platforms? Under Linux 
> it is nice and sufficient to see which modules are missing...

Well ... this might be sort of a problem. You know, *real* end users can get
quite scared if there is something saying 'hey we got a problem here' ;-)
Just trace the list back - a couple of month ago we had this problem that
somebody thought his system was broken because the VM said that it can't
find the AppleScript plugin. I'd say leave it to the support code to print
out any messages if wanted (on Windows I've turned this on only for debug
builds).

  Andreas





More information about the Squeak-dev mailing list