"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