"Raab, Andreas" wrote:
> 
> > I see a problem here:
> >
> > In Interpreter>>isInMissingModules: there I have removed the
> > string/symbol compare for a merely oop compare: So different in oops,
> > but equal in bytes strings would fill up the cache fast, if many
> > different functions from the same module - stored as strings with
> > different oops - are called.

This fills it!

> > This could lead to a bug: there is no caching anymore, if some (>
> > cachesize) different functions each stemming from another module are
> > called in sequence!
> 

Not correctly explained, see below...

> Well, as I said there are only symbols used here. Since this is a cache it
> ought to be fast and I don't consider cache misses for degenerate cases to
> be bugs - not if it means much more expensive comparisons for the common
> case.

I didn't explain the problem correctly, I have meant: If different
functions stemming from different or
the same - if written as strings with different oops -
modules are called, this would fill up the cache, because it is made
assuming one symbol for each module and not some strings - though
bytewise equal - for each module.
Regarding this point there is a fundamental difference between symbols
and strings...

You have written in the earlier mail:
'Note that in the eventual case that there is a String stored in the
module name
the only thing going wrong would be that you'd store the string
explicitly
in the missing module cache (no problem as long as not all modules are
strings which they really shouldn't).'

One example: If there would be only one eventual case, namely a module
stored as string,
but if it also would have many called functions in it then there'd be a
problem: it's not the number of _different_ modules in this case, it is
the number of different string oops for the _same_ module here.

I hope I have elucidated the point now...

As a summary I think it is important to rely on only using symbols as
cached module names!

BTW: I've just seen that at Parser>>primitiveDeclarations there seems to
be the converting from 'moduleName' to #moduleName. What about a short
comment there?

> 
> > But in either case it has to be cleared during startup time.
> > What do you think of is a good time?
> > The cache has to be cleared early before _every_ possible module call.
> 
> SystemDictionary>>clearExternalObjects (or its caller) seems to me the right
> place.

Agreed.

Greetings,

Stephan