Many thanks for these links!
It seems like the GCC JIT interface is the kind of "adaptation" of gcc which I asked for. :-)
Then there's the calling convention problem which Helmut brough up earlier in this thread. But I guess there could be workarounds. In any case one would have to look closer regarding this.
Regarding "hotness":
The original GOOPS implementation had a somewhat crazy feature that an application of a generic function to a specific argument list first resulted in the standard MOP procedure for finding a set of applicable methods and, second, from this/these generated something called a "cmethod" (compiled method) which, in turn, was stored in a cache as well as applied to the list of arguments.
Next time this generic function was applied to an argument list with the same type signature, the *same* cmethod as had been used the first time could be very quickly looked up in the cache. (This lookup is described in doc/goops.mail in the repository.)
The thought behind this was that when a cmethod is compiled, there is knowledge about the specific types of the arguments. This means that a compiler which compiles the applicable method into a cmethod can do some of the type dispatch during compile time, for example that of slot access. This is partially equivalent to unboxing, but more general, since some of the *generic function applications* can have their type dispatch resolved at compile time too. In the most ambitious approach one would include return values in the cmethod type signature---something which is natural to do when compiling to cps. (This type dispatch elimination was never implemented in GOOPS.)
I was curious how much impact this caching scheme of things would have in real-world programs. It turned out to work very well. I'm only aware of one complaint on memory use. Obviously, though, if a generic function with a longer argument list is repeatedly called with different type signatures of the argument list, this could lead to a combinatorial explosion and fill up memory (as well as being rather inefficient).
When Andy re-wrote GOOPS for the new compiler, the cmethod caching was removed---a sensible thing to do in my mind. *But*, some of the downsides of this scheme could be removed if hotness counting was added to the cache. One could do it in various ways. One could be to initially just associate the argument list type signature with a counter. If this counter reaches a certain threshold, the applicable method(s) is/are compiled into a cmethod stored in the cache. The storage of type signatures and counters still has the combinatorial explosion problem. This could now be avoided by limiting the size of the cache such that the counters compete for available space. (There are further issues to consider such as adaptability through forgetting, but I won't make this discussion even more complicated.)
Best regards,
Mikael