On 2009.07.29., at 0:33, Attila Szegedi wrote: > Well, okay, I could go this direction and not even feel particularly > bad about it, except that if I did this, then I'd force all > languages into only having a monomorphic inline cache.
Okay, I solved this. In keeping with the principle that the whole concern of inline caching should be owned by the call site, not the linker, I reduced the linker to a resolver of the method handle and the guard. I introduced a special CallSite abstract subclass named "RelinkableCallSite" that receives them and contains an abstract method responsible for actual linking and/or caching; I also provided a concrete "MonomorphicCallSite" subclass of "RelinkableCallSite" that implements a MIC. Since it's the language runtime that creates the call site anyway, it can choose to use whatever call site subclass it wishes - if its designer is unhappy with the MonomorphicCallSite I provided, he's free to write his own with whatever inline caching strategy he wants. I'm quite happy with how it turned out; I avoided placing constraints on language runtime implementations where none were needed. New code available under <https://sourceforge.net/projects/dynalang/develop>, with README being the most up-to-date document at <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/README.txt?revision=159&view=markup > if you wish to take a look. I'm off to bed now :-) Attila. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
